Reading List
The most recent articles from a list of feeds I subscribe to.
Test in many browsers
I use Firefox as my main browser, both for development and for just regular… browsing. Increasingly, core functionality of websites breaks for me, as, presumably, not all developers test in Firefox anymore.
Yesterday, for instance. I signed up for a conference and their signup form wouldn't submit. It relied on JavaScript, which borked in Firefox. Some ES feature was used that isn't supported in Firefox yet, with no feature checks or fallbacks. As forms have been part of the web for decades, in all browsers, my primary response was ‘hey this shouldn't have to be broken!’
Testing your work in Firefox matters. Right? Well, it does to me, like testing in lots of browsers and assistive tech does. When I shared this on Twitter, realising a little late that this point is controversial, I saw some themes in the responses.
Some said Firefox should test with their websites. They do, actually… Mozilla hosts and sponsors the web compat community which helps debug sites that work in one browser and not another and feeds into improving those browsers. This is really hard and complex work, I remember from hanging out some of the people working on this when I was at Mozilla (the stories…). I recommend Mike Taylor's talk about web compat at View Source 2019.
Others signalled they found it too much work. For a large part of my career, front-end development was all about making stuff work across browsers, because they weren't as well aligned as they are today. I, for one, am so happy to be past the years of needing multiple VMs to test versions of Internet Explorer. With tools like Browserstack and Browsersync, we've come a long way.
Lastly, some said it's ‘not worth it’ given Firefox's marketshare. To be honest, I hadn't checked Firefox's market share before I tweeted and did not realise how small it is today 😢. The percentage is small.
I guess I can understand the idea that organisations prioritise browser support by browser market share. But shouldn't we want browser diversity and browser engine diversity? (This nuance is nicely explained in Brian Kardell's What is actually a web browser?).
Yes, some of the web's smartest and nicest minds work on Chrome and Chromium, I have see them do great work improving the web and prioritise (mostly) the right things over and over. Increasingly so now that the Edge people are also working on making Chromium better. I'm a fan of their work and most of the time Google push the web forward in ways it would simply not have without them. But, as Tim Kadlec mentions in a blog post, they don't always.
It's in everyone's interest to not give one company a near monopoly over what the web can do through their browser, or a handful of companies through their engine (Microsoft Edge, Samsung Internet, Brave and many others also use Chromium). Various people wrote about this when Edge announced they would use Chromium. “No single company, let alone a user-tracking advertising giant, should control the internet”, said Jeffrey Zeldman in Browser diversity starts with us. Competition is about growing, wrote Rachel Nabors, in a post where she compares the browser ecoystem with the world's ecosystem. Hurting engine diversity hurts the web, explains Andre Garzia.
Less browser engines doesn't necessarily mean that all decision making power lies with one company, though. In Beyond Browser Vendors, Brian Kardell mentions the origin story of CSS Grid as an example: originally conceived by CSS co-inventors Bert Bos and Håkon Wium Lie, further worked on years later by Bert Bos, then picked up by Microsoft and ultimately paid for by Bloomberg to be implemented in Webkit and Chromium by teams from Igalia, a company that works on all major browsers and JavaScript engines. This is also how potential futures of the web can be decided.
In any case… I'm curious how thinking may have shifted over the last years. How do you think about browser testing in 2022?
Originally posted as Test in many browsers on Hidde's blog.
Action, inaction and ‘cancel culture’
The health and inclusiveness of a community can be affected by action, but also by inaction. In this post, I'll share some reflections on banning pretty much objectively bad content and on issues with the word ‘cancel culture’.
When a political party tries to attract voters with racism, sexism and homophobia, should all pages on their website be banned from a healthy, inclusive coder community? Last week I got into a discussion I didn't expect I would get into… it could be summarised as this question. (Spoiler alert: to me, the answer is yes).
In one of my communities, someone had shared a link to a blog post on the website of a controversial, far right political party that perpetuates all sorts of racism, sexism, homophobia and misinformation. Just like that, a link in the #general channel that all members join by default, for roughly 7000 people to see, who signed up to collaborate on and talk about code. The blog post itself didn't contain such things per se, but the party owns the website.
In short: I feel such a link should not be allowed on a healthy, inclusive coder community. Failing to moderate this content can make those marginalised by systemic racism, sexism and homophobia feel unwanted. It signals that this community has no specific problems with the link, at least not specific enough to ban it. It could unintendedly scare people away and send out a message about who belongs. Should a community prioritise people who want to share or say whatever they want or people who don't want to have racism, sexism or homophobia affect their daily lives?
My point is… healthy, inclusive communities do the work to make people, especially those who are marginalised, feel wanted. For so many reasons. Sure, banning the post and maybe even the poster could make the poster feel unwanted. That's not great. But… we've got to prioritise the marginalised over the marginalisers (after all, they did post the link).
Do I feel links to all political parties should be banned? No. What about the extreme left or the somewhat right, where does it end? I don't know, but in this case it was easy to tell as this was a party with years of controversies that reasonably go against community spirits. Community members and managers should speak out if they can, remove problematic content actively and reinforce principles. Because not doing that is a message too, and it reinforces something too.
‘Cancel culture’ is the wrong word
I ended up calling for moderation and got into some conversations after that. One person called my request an opinion. Challenging my inner pedant: non discrimination is part of human rights declarations that almost all of the world's countries have signed. A request to reduce discrimination isn't an opinion, it's an attempt to claim basic human rights that whole societies agree on. Except, maybe, in communities of human rights scepticists, but this wasn't one of those.
Others said moderation would be like ‘cancel culture’ or ‘censorship’. The book We need snowflakes by Hannah Jewell, which I happen to be currently reading, does a great job dissecting these frames and the people who use them. Very often, she explains, those who claim to be cancelled ostensibly still have their platforms, be it their job or their status.
The word ‘cancel culture’ is a red flag. When you hear it used, it's worthwile considering how it's employed to shift who the victim is. In The Netherlands, we recently had football club director Marc Overmars ‘cancelled’ for sending female staff photos of his genitals. The word ‘cancel culture’ suggests calling out wrongs is an activity people do for little more than their own entertainment, and that Overmars is now some kind of victim, rather than the women he had literal power over. He was hired in the same position by a Belgian football club weeks later and his Wikipedia page hardly mentions the event (it does have a list of honours). A more apt response would be to ask: how are the women doing?
I am getting carried away a bit, but let's also consider ‘censorship’. Again, paraphrasing Hannah Jewell's book: is one truly censored if no government put rules in place to limit their free speech? If one can still say whatever they want in plenty of other places? If they aren't arrested for what they did? The ‘censorship!1!’ exclaimers should compare what they're exclaiming about to actual censorship that sadly happens in various states around the world.
In healthy communities, asking someone to remove content is simply a request to stop their harm in a specific community. Because it happens to be a community that has a principle on whose feelings to prioritise. Because that matters.
Originally posted as Action, inaction and ‘cancel culture’ on Hidde's blog.
The URLs are new
This blog has had pretty long URLs for legacy reasons. Today I've made some updates to change that.
Redirects and RSS should all work, though some feed readers seem to surface old posts as unread, sorry for any inconvenience.
For context, this used to be my company's website. I only really ever updated the blog section, so I decided to make that the main thing. The old structure lasted just over 8 years and my hope is that the new one will break that record.
URLs are such a cool part of the web, especially if they're set up thoughtfully. Like traintimes.org.uk, where you can add /london/bristol to get times for trains from London to Bristol, and /9:00 to that if you want the ones that leave from 9am.
I don't know of ways to give blog URLs very thoughtful structures, there isn't a lot of structure in this blog anyway. Anne van Kesteren's classic post on how to do blogs has some good pointers, like where an archive should live.
New blog post URLs
On this blog, a post URL used to be something like:
hiddedevries.nl/en/blog/2022-04-02-my-post
It's now:
hidde.blog/my-post
The main changes are:
- new host name, reducing lots of characters, easier to remember and put on slides
- single language setup, removing the need for
en - no more dates in the URL structure
I wasn't super sure about removing dates, so I asked on Twitter. I didn't have a specific reason for including dates before, it was a default of my CMS and I kind of liked it at the time.
Dates matter
A couple of people replied to my question that dates on blog posts are important to readers. Especially for blog posts that share technical advice, as they could go out of date.
Other reasons for including a date are:
- a less messy file system, if you put posts into actual folders in the file system; this is moot if your routes are handled by some system
- it can be helpful for blog owners that code to have the date as part of the file name
- prevents naming collisions
- it's nice for analytics
- it's a default in a lot of blog software or a choice from the past
- it provides context
But there are drawbacks too:
- date is usually creation date, this could make posts seem old, while the author may be frequently keeping content up to date, this could be confusing
- dates are really metadata, they don't belong in the URL
- it's not as simple and readable
I've gone for simplicity. I do agree dates matter though, especially on tech posts, so I have the publication date in the post content near the title (I do use GitHub's <time-ago> Web Component to display it relatively). I also include dates when I make updates, though I add those at the end rather than near the title (I probably want to improve that).
That's all for today. I've also moved away from the CMS, so if you notice anything is broken, please do slide in my DMs or email my first name at hiddedevries.nl.
Originally posted as The URLs are new on Hidde's blog.
Common accessibility issues that you can fix today
WebAIM have come out with their latest report on which accessibility issues they found in the top million websites that they tested automatically. What is some low hanging fruit you could fix today?
For context, WebAIM, a non profit based out of Utah in the US, have done their ‘WebAIM Million’ project since 2019. They post an extensive analysis every year, looking at trends and improvements/decline in web accessibility over time. I find these posts very insightful and use them to inform my own workshops and outreach. It’s definitely recommended reading!
There are some caveats to be added with surveys based on automated accessibility testing. One is that ‘ease of detectability’ does not correlate with ‘impact on end users’. There are issues that are easy to detect and issues that impact end users most, these are not necessarily the same. Automated tests also cover only a small part of all accessibility, as some things aren’t detectable by machines (yet, or ever). I’m not suggesting this makes the survey less useful or good, but wanted to call it out explicitly. The ACT-Rules Community Group at the W3C works on harmonising test rules for things that are testable.
Ok, let’s look at the top issues and how developers, browsers and CMSes can take away barriers today. Some of these include ideas about what users can do (important caveat: none of this should be user responsibility, website owners should not expect users to use or know about these tools).
Low text contrast
There are cases where text colour and the background colour have a ratio lower than the threshold in WCAG (see also MDN on contrast).
Designers can check contrast manually install plugins (using a tool like Contrast Ratio) or install a plugin like Stark for Figma or Sketch.
Developers can use an automated contrast checker to make sure you avoid low contrast text. Run a checker like the one in Firefox Dev Tools Accessibility Panel or axe in CI/CD, or paste two colours into a manual tool like Contrast Ratio.
Designers and developers alike can use Polypane’s contrast checker that suggests accessible alternatives, which makes it a lot easier to not just find the issue, but also fix it while you’re at it.
Users could use a plugin like Fix Contrast to not be affected: it tweaks colours on the fly so that you don’t have to suffer low contrast text.
There are some discussions on new colour contrast algorithms for WCAG, but this is still under discussion and not ready any time soon.
Missing alternative text
When you create content, describe your images. In your CMS, on Twitter and even in GitHub issues: use that alternative text feature, so that users who can’t see the image can access the content in them. On platforms that don’t support alternative text, like Slack or mobile LinkedIn (!), you can describe images in text. If you choose a CMS or content platform, ensure it can handle alternative text or set it up to do so.
In the resulting HTML, you’ll want something like:
<!-- image with text -->
<img src="website-logo.png" alt="hiddedevries.nl" />
<!-- image with redundant content -->
<img src="hidde.png" alt="" />
<p>Photo of Hidde</p>You can make your decisions on alternative text using the Alt Decision Tree, but basically the gist is that if you were to replace your image with a square, what would you write in the square for it to still be useful? Leaving it empty is an option if that’s the most useful alternative for the image.
Users can use Microsoft Edge, which fills in missing alternatives. AI aren’t very good at intentions or context, but pretty much perfect at recognising text. Next time a news website posts an image of new covid rules with no alternatives (as the main Dutch news website used to do throughout the pandemic), users of Edge can follow along.
Empty links and buttons
When links, buttons or other interactive elements don’t have names, assistive technologies like screenreaders or voice controls have no way to uniquely refer to them. If it is to be interacted with, it needs a name.
Names are derived from text content, like the actual text that’s inside a button, or can be added through an attribute. See Naming things to improve accessibility for more detail or the spec that defines how controls get their names.
Developers need to ensure all controls they build (links, buttons, form fields, etc) have names, ideally that make sense out of context:
<!-- names that make sense out of context -->
<button>Submit form</button>
<button>Publish content</button>
<button>Expand filters</button>
<a href="//wikipedia.org">Wikipedia</a>
<a href="//twitter.com">Hidde on Twitter</a>
<!-- names that are confusing -->
<a href="/">click here</a><!-- avoid -->
<a href="/>read more</a><!-- avoid -->
<!-- names that are missing; avoid or add a name -->
<a href="//twitter.com/"><svg/></a><!-- avoid -->
<a href="//linkedin.com"><img src="" alt="" /></a><!-- avoid -->
<button><img/><button><!-- avoid -->Browsers can sometimes derive names from nearby text, some do this when there is no text to derive a name from. This is not ideal, can lead to wrong and confusing guesses and be bad end user experience. The developer of this control will know best what the thing does and therefore how it should be named.
Missing form labels
Form labels kind of fall under naming things, as they name form elements specifically.
Developers can fix this by ensuring form fields have a <label> element of which the for attribute points to the id of the input/select/textarea, this also makes that clicking label moves the cursor to the input:
<!-- “for” and “id” are same, this connects them -->
<label for="field">Address</label>
<input id="field" />They can also add an aria-label attribute to the input to name it that way (but be careful, ARIA labels don’t get translated well).
Missing languages
Proper language indication can get you a Pass on two (!) WCAG Success Criteria (3.1.1 and 3.1.2), and you only need to know one attribute for it.
Developers should ensure the <html> element has a lang attribute with the right language:
<!-- marks this document as 'in English -->
<html lang="en">Sometimes this is forgotten as the <html> element lives in some template you never touch, but it’s not hard to do, so always double check that this attribute exists and is set to the right language.
If there is content on part the page that is in another language, mark that too, again, with a lang attribute on the relevant DOM node. When you pick a plugin for internationalisation, ensure it sets the langs or makes it easy for you to do so.
CMSes can make sure that lang attributes are set and set correctly. Browsers can guess languages, but they aren’t always good at this, specifically when it comes to distinguishing dialects: they often matter a lot to people, less so to machines.
Wrapping up
These are some tips based on the most common issues that WebAIM Million 2022 identified. Let’s all put in the work to make sure we, our colleagues, our clients and our users avoid these issues. Like, actually. We need WCAG auditors to focus on higher hanging fruit, by fixing the lower hanging stuff for good.
If this is all new to you, hi, thanks for reading! I hope this helps and feel free to get in touch with questions. If you already knew all of this, please keep spreading the word, so that in next year’s survey, we’ll see steady improvements for the web at large.
Want to learn more about fixing low hanging fruit accessibility issues? In response to the same survey, Christian Heilmann blogged about how to fix accessibility issues using your browser
The post Common accessibility issues that you can fix today was first posted on hiddedevries.nl blog | Reply via email
Common accessibility issues that you can fix today
This week, WebAIM published their latest “WebAIM Million” report. It details accessibility issues they found when they tested the web's top million websites automatically. What is some low hanging fruit you could fix today?
For context, WebAIM, a non profit based out of Utah in the US, have done their ‘WebAIM Million’ project since 2019. They post an extensive analysis every year, looking at trends and improvements/decline in web accessibility over time. I find these posts very insightful and use them to inform my own workshops and outreach. It’s definitely recommended reading!
There are some caveats to be added with surveys based on automated accessibility testing. One is that ‘ease of detectability’ does not correlate with ‘impact on end users’. There are issues that are easy to detect and issues that impact end users most, these are not necessarily the same. Automated tests also cover only a small part of all accessibility, as some things aren’t detectable by machines (yet, or ever). I’m not suggesting this makes the survey less useful or good, but wanted to call it out explicitly. The ACT-Rules Community Group at the W3C works on harmonising test rules for things that are testable.
Ok, let’s look at the top issues and how developers, browsers and CMSes can take away barriers today. Some of these include ideas about what users can do (important caveat: none of this should be user responsibility, website owners should not expect users to use or know about these tools).
Low text contrast
There are cases where text colour and the background colour have a ratio lower than the threshold in WCAG (see also MDN on contrast).
Designers can check contrast manually install plugins (using a tool like Contrast Ratio) or install a plugin like Stark for Figma or Sketch.
Developers can use an automated contrast checker to make sure you avoid low contrast text. Run a checker like the one in Firefox Dev Tools Accessibility Panel or axe in CI/CD, or paste two colours into a manual tool like Contrast Ratio.
Designers and developers alike can use Polypane’s contrast checker that suggests accessible alternatives, which makes it a lot easier to not just find the issue, but also fix it while you’re at it.
Users could use a plugin like Fix Contrast to not be affected: it tweaks colours on the fly so that you don’t have to suffer low contrast text.
There are some discussions on new colour contrast algorithms for WCAG, but this is still under discussion and not ready any time soon.
Missing alternative text
When you create content, describe your images. In your CMS, on Twitter and even in GitHub issues: use that alternative text feature, so that users who can’t see the image can access the content in them. On platforms that don’t support alternative text, like Slack or mobile LinkedIn (!), you can describe images in text. If you choose a CMS or content platform, ensure it can handle alternative text or set it up to do so.
In the resulting HTML, you’ll want something like:
<!-- image with text -->
<img src="website-logo.png" alt="hiddedevries.nl" />
<!-- image with redundant content -->
<img src="hidde.png" alt="" />
<p>Photo of Hidde</p>You can make your decisions on alternative text using the Alt Decision Tree, but basically the gist is that if you were to replace your image with a square, what would you write in the square for it to still be useful? Leaving it empty is an option if that’s the most useful alternative for the image. Like in the example above, there is a photo with a paragraph underneath that describes it. In this case, writing “Hidde” or “Photo of Hidde” in the alt attribute is redundant, it would be best to use an empty alt (but do leave the attribute in there, or some browsers will use the image URL as an alternative).
Users can use Microsoft Edge, which fills in missing alternatives. AI aren’t very good at intentions or context, but pretty much perfect at recognising text. Next time a news website posts an image of new covid rules with no alternatives (as the main Dutch news website used to do throughout the pandemic), users of Edge can follow along.
Empty links and buttons
When links, buttons or other interactive elements don’t have names, assistive technologies like screenreaders or voice controls have no way to uniquely refer to them. If it is to be interacted with, it needs a name.
Imagine the difference between a screenreader saying “here's 4 buttons: button, button, button and button”, versus “here's 4 buttons: publish content, delete content, change to draft, upload image”. In the first instance, you'd need to press them before you know what they do, in the second, it is clear what you're in for, with no further context needed.
Names are derived from text content, like the actual text that’s inside a button, or can be added through an attribute. See Naming things to improve accessibility for more detail or the spec that defines how controls get their names.
Developers need to ensure all controls they build (links, buttons, form fields, etc) have names, ideally that make sense out of context:
<!-- names that make sense out of context -->
<button>Submit form</button>
<button>Publish content</button>
<button>Expand filters</button>
<a href="//wikipedia.org">Wikipedia</a>
<a href="//twitter.com">Hidde on Twitter</a>
<!-- names that are confusing -->
<a href="/">click here</a><!-- avoid -->
<a href="/">read more</a><!-- avoid -->
<!-- names that are missing; avoid or add a name -->
<a href="//twitter.com/"><svg/></a><!-- avoid -->
<a href="//linkedin.com"><img src="" alt="" /></a><!-- avoid -->
<button><img/><button><!-- avoid -->Browsers can sometimes derive names from nearby text, some do this when there is no text to derive a name from. This is not ideal, can lead to wrong and confusing guesses and be bad end user experience. The developer of this control will know best what the thing does and therefore how it should be named.
Missing form labels
Form labels kind of fall under naming things, as they name form elements specifically.
Developers can fix this by ensuring form fields have a <label> element of which the for attribute points to the id of the input/select/textarea , this also makes that clicking label moves the cursor to the input:
<!-- “for” and “id” are same, this connects them -->
<label for="field">Address</label>
<input id="field" />They can also add an aria-label attribute to the input to name it that way (but be careful, ARIA labels don’t get translated well).
Missing languages
Proper language indication can get you a Pass on two (!) WCAG Success Criteria (3.1.1 and 3.1.2), and you only need to know one attribute for it.
Developers should ensure the <html> element has a lang attribute with the right language:
<!-- marks this document as 'in English -->
<html lang="en">Sometimes this is forgotten as the <html> element lives in some template you never touch, but it’s not hard to do, so always double check that this attribute exists and is set to the right language.
If there is content on part the page that is in another language, mark that too, again, with a lang attribute on the relevant DOM node. When you pick a plugin for internationalisation, ensure it sets the lang s or makes it easy for you to do so.
CMSes can make sure that lang attributes are set and set correctly. Browsers can guess languages, but they aren’t always good at this, specifically when it comes to distinguishing dialects: they often matter a lot to people, less so to machines.
Wrapping up
These are some tips based on the most common issues that WebAIM Million 2022 identified. Let’s all put in the work to make sure we, our colleagues, our clients and our users avoid these issues. Like, actually. We need WCAG auditors to focus on higher hanging fruit, by fixing the lower hanging stuff for good.
If this is all new to you, hi, thanks for reading! I hope this helps and feel free to get in touch with questions. If you already knew all of this, please keep spreading the word, so that in next year’s survey, we’ll see steady improvements for the web at large.
Want to learn more about fixing low hanging fruit accessibility issues? In response to the same survey, Christian Heilmann blogged about how to fix accessibility issues using your browser
Originally posted as Common accessibility issues that you can fix today on Hidde's blog.