Happy New Year! 🎉 New year, new look: you may have noticed the format for this month’s issue is different. I’ve separated each article by heading, and mostly 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.

The endless search for “here” in the unhelpful “click here” button

• Eric Bailey articulates all the reasons why you should stop using links and buttons with the text value “here” or “click here”. This is such a common mistake across the web and is a habit we need to break out of.
• Compare the following two sentences:
  1. Click here to learn about how to roast Brussels sprouts
  2. Learn how to roast Brussels sprouts
• The former makes no sense out of context. If a screen reader user pulls up a list of all links in the page, they’re not going to know what “click here” is referring to. “How to roast Brussels sprouts” is the main action, and makes sense on its own. The latter also has a greater surface area to click on. Finally, some users activate links by saying the name of the link; the latter works well for that, whereas the former would be problematic if there were several links called “click here”.
• Now consider these instructions: “Click the button below”. There are two problems here:
  • “Click” only makes sense in a desktop/laptop mouse context. It doesn’t make sense for keyboard or touchscreen users. Yes, they’ll probably still understand what to do, but that doesn’t mean we can’t use more universal language, such as “Select”.
  • “Below” is also problematic. What if our content has been translated into a vertically-oriented language, and therefore makes no sense? What if the design is different for desktop, such that the link ‘below’ is actually to the side? What if we’re reading this in VR – does “below” now mean someone will think it’s underneath them? The web is a highly malleable place. Better to use language like “next/previous” or “following/preceding”.
• Eric ends by pointing to the proposed CSS Logical Properties module. This favours “start/end” properties rather than the more traditional “top/right/bottom/left”, as the latter have an implicit default writing mode of left-to-right & top-to-bottom – not a good look for a global technology.

WebAIM guidance on Alternative Text

• This guidance was given a fresh update in October 2021, so I’m reading it anew.
• “Although technology is getting better at recognizing what an image depicts, algorithms alone cannot understand what an image means within the context of the overall page. A maple leaf might represent Canada, or it might just illustrate the leaf of a tree.”
• There are several examples of good vs bad alt text, and clarifications around when an empty alt text is appropriate. But I knew that already, so have cherry-picked some of the more interesting content in the points that follow.
• Other than the alt attribute, “alternative text can be presented within visible body text near the image” or even “on a separate page, linked from either the image or a text link adjacent to the image” (but only “when the text equivalent cannot be presented succinctly”). Note that the longdesc attribute is deprecated and should not be used.
• A trip down memory lane: image maps. The main image associated with the <map> must have an alt attribute that describes the content within the image, but is not otherwise presented with each image map hot spot. For example, a State of New York map that has an <area> for each county might have alt="Counties of New York", whereas its hot spots would each have an alt attribute containing the name of the county. If the main image does not convey content (just a container for the hot spots), then alt="" is appropriate.
• Finally, a note on <figure> and <figcaption>. The <img> within the <figure> must have non-empty alt attribute, which should not just be a repeat of the <figcaption> contents. I was surprised by this, so I read the linked How do you figure? blog post by Scott O’Hara. Some highlights from that post:
  • “One of the biggest misunderstandings of using a figcaption is that it’s used in place of image alternative text”.
  • “A figcaption is meant to provide a caption or summary to a figure, conveying additional information that may not be directly apparent from reviewing the figure itself. If an image is given an empty alt, then the figcaption is in effect describing nothing. And that doesn’t make much sense, does it?”
  • Moreover, using an empty alt="" on the image causes serious screen reader issues. It’s essentially the same as an <img alt="" /> anywhere else in the page; in other words, it’s treated as decorative, and ignored by the screen reader. So an empty alt="" will mean your entire <figure> gets skipped over.

VR Game Gravitational Blends Puzzles With Real Accessibility Challenges

• Electric Monkeys Studio has built a VR game set in the future, in a scientific facility where gravitational technology is being discovered. The protagonist, Sebastian, uses a wheelchair, presenting an extra challenge in navigating the environment after an explosion destroys much of the facility, as you have to find ways around obstacles in your path.
• It’s promising to see more representation of wheelchair users, adding to games like Life is Strange and Sly Cooper. In November 2020, Bethesda added wheelchairs to Fallout 76 after a fan asked the developer to add her aid to the game.
• The article lacks detail on the gameplay, but there are a few reviews on Steam. Whilst there are complaints around the graphical quality and the controls, one positive reviewer goes into detail about some of the accessibility constraints forced on the player, which I thought was interesting:
• “You can’t look around very much without seeing the start of ‘tunnel vision’ and colors fading, and a red icon reminding you to push a button to re-orient. I accept this because a person with paralysis mainly turns their head, not their body. In real life, such a person has to make big adjustments just to see in a different direction. Yes, it’s annoying, and holds you back. I accept it as simulating part of what it feels like to be this person.”
• As a VR player myself, one of the most immersion-ruining aspects is movement. Pressing a button to walk or run kind of pulls you out of the experience (and can cause motion sickness), so to have a game where being seated matches what your character is doing, is quite a clever solution to the problem.

Adding A Dyslexia-Friendly Mode To A Website

• Smashing Magazine article by John C Barstow. I thought this was going to be one of those “choose a dyslexic-friendly font” type article, but it covers a lot more than that!
• According to John, “research shows that standard fonts like Helvetica and Times New Roman are just as readable as purpose-built fonts like Dyslexie or Open Dyslexic”. He goes on to clarify that the most important factor is the spacing between letters and words. The reason fonts like Comic Sans are so popular with dyslexic readers is the wider spacing found in that font.
• We can increase the letter spacing of our chosen font using the ch unit, which is based on the size of the 0 glyph – often a good approximation of the average character width. John comes up with this CSS: .dyslexia-mode { letter-spacing: 0.35ch; word-spacing: 1.225ch; }, which gives a 3.5x letter spacing.
• Ligatures are when multiple characters are merged into a single glyph; you’ll often see this when “f” and “i” are rendered next to one another, forming a joined-together “fi”. Dyslexic readers may struggle with ligatures, so we can disable the feature with font-variant-ligatures: none, though this may be disabled automatically by some browsers when the letter spacing is set high enough.
• I learned about Heydon Pickering’s owl selector (* + *), which can be used to apply consistent line-spacing, e.g. * + * { margin-top: 1.5em }.
• John finishes up by applying a slightly bigger font weight to his text, to counteract the extra whitespace (font-weight: 600, which is “demi-bold”, apparently). He also applies style to his bold text, to differentiate it from the demi-bold regular text: .dyslexia-mode strong { color: #000 }.
• There’s also a tip around avoiding unnecessarily distracting elements, such as background images, for which you can use the :not pseudo-class. Example: body:not(.dyslexia-mode) main { background-image: url("...") }.
• The article concludes with a CodePen showing the before-and-after. The comments below the article are also worth a read.

Collaborative planning, the forgotten step of accessible development

• A deque article describing “a11yBID”, or “Accessibility Business Informed Development”.
• It’s essentially BDD (“Behaviour Driven Development”), in that it involves conversations between stakeholders and cross-functional team members to define Acceptance Criteria (AC), often in a formatted plain language format called Gherkin.
• a11yBID is different to BDD as it “doesn’t discover classic business requirements as BDD does. Instead, it clarifies the accessibility-specific aspects of those business requirements”.
• Starting with high-fidelity designs (i.e. PDFs), the process begins with an “a11y Amigos” meeting between the designer, the tester and the business analyst. The group reviews the design from an a11y perspective, asking questions around focus management etc, and drafting the “a11yAC” user stories. Here is an example of one:
  • Scenario: A blind screen reader user can understand that content is loading
  • Given I am a blind screen reader user
  • And I have submitted the form
  • And a loading spinner is visible as I await a response from the server
  • When I navigate to the loading spinner image
  • Then I hear the image role
  • And I hear the alt text as “loading”
• The article concludes with some general advice to make a11yBID scale. For example, making use of a design system and component library, so that you can reuse tried-and-tested designs.

The CSS “content” property accepts alternative text

• Stefan Judis writes about a CSS feature I didn’t know about. You should subscribe to Stefan’s newsletter too!
• The before/after pseudo elements are often paired with content to add text or icons next to your elements. Example: .item::before { content: "★" }. Used in HTML, <a class="item" href="#">new story</a> would be read out by screen readers as “black star new story”.
• The content property supports alternative text. The code looks like this: .item::before { content: "★" / "Highlighted" }, which would now read as “Highlighted new story”.
• If the icon is purely decorative, an empty alt value of "" is probably more appropriate. That would also avoid the problem of CSS content not necessarily being auto-translatable.
• This feature is only supported in Chromium browsers (i.e. not Firefox/Safari, though there is a hack to get it working in Safari). Therefore using a separate element for your icon, and applying aria-hidden="true" to it, is probably the better approach.

Niagara-made audio game nominated for accessibility Game Award

• The Vale: Shadow of the Crown, by Falling Squirrel games company, is an audio-only game, released in August 2021.
• The game gained a nomination at this year’s Game Awards (which was watched by 80 million people in 2020).
• I found a more informative article on digitaltrends, which notes that the games origins weren’t “altruistic” in nature; the studio director simply didn’t have any design experience, so wanted to build a game on a scale that he could afford!
• “The story centers around Alex — a feisty, intensely brave, and blind princess — and her companion, Shepherd, and their journey to save their realm from destruction”. The game uses 3D audio technology and controller feedback to immerse the player in the story. There are no visuals other than the menu, which can also be navigated by audio only, i.e. this game is fully accessible to visually impaired players.

---

Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♥ by developer @ChrisBAshton.