Happy New Year! 🎉 New year, new look: you may have noticed the format for this fortnight’s issue is different. I’ve separated each article by heading, and done away with the bulletpoint list format. The old format never felt quite right, and made things like code examples difficult to add, but it did help keep the word count down! I’ll try to keep being concise. Please do drop me an email to let me know what you think about the new format!
Without further ado, on with the issue.
How many people with disabilities use our site?
Hidde Devries writes the one article that you’ll want to direct people to whenever they ask that question.
Implicitly, the person who asked that question is trying to find the return on investment. Hidde asks “what will we do with that data? What if it is a very low percentage? Whatever it is, equal access is still the right thing to aim for, a human right that is required by law”. He quotes:
When we work on making our devices accessible by the blind, I don’t consider the bloody ROI. When I think about doing the right thing, I don’t think about an ROI. If that’s a hard line for you, then you should get out of the stock.
Apple CEO Tim Cook
Hidde points out too that even if we could get an accurate number – and we can’t, due to the user’s privacy being more important than our analytics – it doesn’t show the market potential. It doesn’t show how many disabled users have turned to competitors because they couldn’t access your site.
Finally, making accessibility improvements will often benefit more people than just the intended audience. Think of a ‘dark mode’, which many people like to set, not just those who want to avoid headaches etc.
In short, Hidde’s standard answer to this question is this:
We can’t measure assistive technology usage for (good) privacy reasons, our analytics won’t show customers that went to a more accessible competitor, and accessibility benefits everyone.
Dyslexic Myths Presented as Truths
Gareth Ford Williams writes about the Smashing Magazine article Adding A Dyslexia-Friendly Mode To A Website, which I covered in dai11y 13/12/2021. He is highly critical of it, both here and as a comment on the article itself, for the following reasons.
Firstly, the entire concept of a ‘dyslexia mode’ is “appalling”; Gareth touches on the ethics and possible GDPR breaches by building such a mode, especially if it allows us to ‘diagnose’ users and store this medical information in a cookie or in a profile.
A lot of the advice in the article, Gareth claims, is aimed at accommodating users who have Irlen Syndrome, not dyslexia. The former is a problem with the brain’s ability to process visual information, whereas the latter is an audio condition. Gareth also says some of the advice, such as “fewer distractions”, are for other cognitive groups such as ADD, ADHD or ASD.
The research quoted in the article has “only 27 subjects, all the same age, in the same class”, so not a reliable sample size. Gareth also argues a lot of the points around font choices, use of Comic Sans etc is presented without evidence.
Thanks to James Buller for notifying me of Gareth’s response to the article. I’ve now added a disclaimer to my previous dai11y article, pointing to this one.
Accessibility monitoring of public sector websites and mobile apps 2020-2021
This report details how the Central Digital and Data Office (CDDO) monitored around 600 public sector websites for accessibility issues over almost two years. They tested based on the EN 301 549 standard, version 2.1.2, which maps closely to WCAG 2.1 accessibility levels A and AA.
Accessibility issues were found on “nearly all” of the sites. The CDDO would send a report to the website owner and check again after 12 weeks, by which time 59% had fixed the issues or set “short-term deadlines” for fixing the remaining issues. 20% of organisations did not respond to the initial contact.
“Disproportionate burden may be claimed where the impact of fully meeting the accessibility regulations is too much for an organisation to reasonably complete”. 32% of websites contacted claimed disproportionate burden. Some of these provided detailed reasoning as to the costs and benefits to their users. Some organisations were grateful for their audit report, which was sometimes the first they’d heard about accessibility regulations. Others did not respond positively; one stated it “took valuable resources away from priority pandemic-related work”.
The most common issues were a lack of keyboard focus styles, low colour contrast and “parsing issues” (e.g. no label associated with form input). Accessibility statements are becoming out of date (many were published in September 2018/2019), with just 7% containing all required information. By the end of the monitoring process, 80% had full compliance.
The report details what tools CDDO used and how the audit was conducted. Worth a read!
On the <dl>
Ben Myers walks us through the <dl> (‘description list’ – previously ‘definition list’ prior to HTML5) element. Name-value pairs are a common UI pattern you’ll have seen all over the place, for example:
Publisher: New Riders Pub; 3rd edition (October 19, 2009)
Language: English
Paperback: 411 pages
You could mark this up as a series of <div>s, but a screen reader user would lose out on benefits such as knowing how many name-value groups are in the list, and skipping over the list. It is better to use semantic markup, like so:
<dl>
<dt>Publisher</dt>
<dd>New Riders Pub; 3rd edition (October 19, 2009)</dd>
<dt>Language</dt>
<dd>English</dd>
<dt>Paperback</dt>
<dd>411 pages</dd>
</dl>
You can use multiple <dd> (description detail) elements per <dt> (description term) if appropriate, e.g. associating multiple authors with a book. Just list the multiple <dd>s one after the other.
You are also allowed to wrap your <dt>Foo</dt><dd>Bar</dd> element groups with a <div></div>, if needed, for style purposes. This is the only element that is allowed to wrap these.
If you have multiple description lists in your page, you can differentiate them by adding an aria-label attribute to each <dl> element.
WCAG 3 is not ready yet
Article by Eric Eggert, reminding people that WCAG 3 won’t be released for another 3-5 years. The new standard is still in draft form and is subject to change. Commercial and public projects are, generally, required by law to comply to WCAG 2, and WCAG 3 is not backwards compatible, so we must take care to continue to abide by WCAG 2 in the meantime. WCAG 2.1 is the latest official standard, with 2.2 coming sometime this year.
Eric focuses in on the new colour contrast algorithm that’s coming in WCAG 3: “the visual contrast algorithm, APCA, is a stark departure from the luminosity contrast algorithm used in WCAG 2”. Unlike in WCAG 2, APCA takes font face, size and weight into account, better representing how colour perception works in practice. The trade-off of extra complexity “might be totally worth it”, but there is little actionable advice in the specification at time of writing.
If we were to have a “modular WCAG”, similar to what CSS is doing, we could package up new success criteria into a new version. Eric says this would give room to change ratings and evaluation guidelines per criterion, without having to release a new major version. It’s an interesting thought!
Fix web accessibility systematically
Another WCAG 3 related post by Eric Eggert, who claims the new standard will not be the silver bullet some people think it will.
Eric laments the current situation of accessibility technologies: the complex set of documents including WCAG 2, ATAG 2 (standards for authoring tools), UAAG 2 (for browsers / user agents), ARIA, ARIA Authoring Practices (designed to be technologically neutral, so lacking HTML best practice), HTML Accessibility API Mappings and ARIA in HTML. This is a complex world for developers. ““Don’t use ARIA unless you have to” is a common phrase uttered by accessibility experts, but how are ordinary developers supposed to know when they have to?”
The situation isn’t helped by a lack of interoperability, and a lack of traction in browsers. <input type="date"> has been standardised for over a decade, but still “lacks accessibility support in modern browsers”. Early thoughts around ARIA were that “most aspects of it would be converted into native HTML quickly: combo boxes, dialogs, tab panels”, etc – but a world with natively accessible features right out of the box “did not come to pass”. Instead, ARIA is now a meta language that sits between technologies, defining an accessibility vocabulary for them. ARIA takes on features of HTML, instead of the other way around.
Releasing a new WCAG version will not fix the situation: Eric wants to see much more work done in browsers themselves. Making a form input with a missing label should trigger a console warning for developers. Standardising accessibility support in native elements would greatly simplify documentation and improve reliability. The easier accessibility is to teach, the more accessible the resulting websites.
https://buttonbuddy.dev/
A useful micro website by Stephanie Eckles. It explains the requirements for accessible contrast on buttons, and includes a generator for creating buttons of sufficient contrast.
You have the option of using a colour picker, or switching to “Use text input” mode to put in the CSS hex codes that you intend to use. The generator will then tell you whether or not the button has sufficient contrast, factoring in whether or not the button will be used with ‘large text’ (which is subject to different contrast requirements, detailed on the website).
The world’s most accessible websites
This is a study by ToolTester.com, but take its findings with a big pinch of salt.
The study looks at “the 200 most popular websites in the world”. This list of sites was allegedly “collected from data by Similarweb”, but comparing the study data with the top websites on similarweb.com, a lot of moderation has evidently taken place: the study omits adult websites, non-English websites, and (inexplicably) Reddit.
asos.com is deemed the ‘least accessible’ site, with the “percentage of site inaccessible” graded as 21.38%. This story has been covered by the Mirror and also covered by ChargedRetail.co.uk, which is what brought my attention to the study in the first place. Both news sources implied that the 21% figure applies to the whole website – the Mirror even headlines ‘1 in 5 pages blocked’ – but according to the ToolTester methodology (at the end of the study), only the homepage was tested.
ToolTester used ‘Arc Toolkit’ – a Chrome extension – to perform automated tests across these sites. It doesn’t look as though any manual testing was performed. For these reasons, I really think this study is lacking in detail and substance, but it’s an interesting data point nonetheless.
ASOS performed poorly due to errors including poor colour contrast, missing ARIA and missing labels. Instagram came second in inaccessibility, lots of user generated content with no alt text causing the bulk of issues, but there are other more easily fixable issues, including a lack of alt text on the login page and a lack of ARIA labels on play buttons. Facebook also makes the bottom 10 list.
Government websites NIH.gov, CDC.gov and GOV.UK fared best, with LinkedIn, H&M, PayPal and Amazon not far behind. All of these websites had more than 99% of their ‘site’ (read: homepage) considered accessible.
Amazing haptic speaker lets visually impaired people read braille in midair
This is not a new article, but has been in my bookmarks since May 2020. Researchers at Bayreuth University in Germany have developed a speaker system which emits ultrasound waves that allow people to read braille in mid-air. The research is particularly pertinent during this coronavirus pandemic, where avoiding touching public surfaces is generally a good thing!
The technology is made up of a 16×16 grid of speakers, and can detect a hand up to a distance of 70cm.
You can read the full academic study, “HaptiRead: Reading Braille as Mid-Air Haptic Information“.
Don’t make users switch caps letters to lowercase
A quick tip by Stas Melnikov: add autocapitalize="off" attribute to your text input to have mobile browsers open a lowercase keyboard (as opposed to an all-caps keyboard). This is well suited to login forms which ask for the user’s email address.
Accessibility of Content Management Systems – what’s stopping us?
Back in October 2020, I wrote about how W3C decided not to use WordPress because it was considered inaccessible. They opted for the proprietary Craft CMS instead, as “the Craft team had made the commitment for Craft v4 to comply with ATAG AA standards“. At the time, this spawned a bit of an internet war, pitting ‘accessibility’ against ‘open source’.
In today’s article (also available as a video, 26m), Marie Manandise reflects on her role at Studio 24, the agency tasked with redesigning the W3C site. Marie’s job was to choose the right CMS.
Marie talks of “the accessibility paradox”, where CMS providers all claim to “care very much about accessibility”, even when none of them are considered accessible. She suggests that we take for granted how difficult accessibility is to get right, and what resources are needed.
For example, to properly test that website navigation is accessible to a non-sighted user, Marie says you need to do paired testing: a sighted and non-sighted user sitting side by side, in front of a screen. And that you need to test in the same manner every time you update your website.
CMS developers “don’t have the knowledge to make the assessment” as to whether or not their CMS is accessible. “Most of us are clueless at accessibility”. Accessibility groups embedded in CMS vendor organisations tend to be “operating in the margins”. Marie says that accessibility experts have an image problem, and don’t carry the “aura of security experts, for example”.
So what can we do about it? Echoing Eric Eggert’s points the other day, the answer is to simplify the learning material / specifications, and to ensure that accessibility is on the curriculum at courses and bootcamps.
Did you know that you can subscribe to dai11y, week11y, fortnight11y or month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with ♥ by developer @ChrisBAshton.
