Happy New Year! 🎉 It’s been three weeks since the last issue of week11y, after a much needed break.
New year, new look: you may have noticed the format for this week’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, though this week is an exception, as it covers a whopping six articles. Please do drop me an email to let me know what you think about the new format!
Without further ado, on with the issue.
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.
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.
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!
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.
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!
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.
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.
![Share presentation in html (for screen reader users and magnification users):
https://docs.google.com/presendation/d/[link censored]/htmlpresent](https://pbs.twimg.com/media/FD74f3hWQAQ8BUO?format=jpg&name=large)