We begin with some special WCAG 3.0 coverage, in which I’ve read and summarised a two-parter by deque.
- WCAG 3.0 is designed to be easier to learn than its predecessors. Instead of ‘success criteria’, we have ‘outcomes’. The former concern the content of a web page, and are evaluated as either a pass or a fail. The latter are centered around user needs, and are scored from 0 (very poor) to 4 (excellent).
- Instead of using levels A, AA and AAA, WCAG 3.0 uses bronze, silver and gold. The current working draft of WCAG 3.0 only focuses on the bronze level, which is roughly equivalent to WCAG 2.1 A and AA compliance. WCAG 3.0 is not likely to be published as a W3C recommendation until 2023 at the earliest.
- WCAG 3.0 has a concept of ‘critical errors’, an example of which would be if an image missing alternative text prevents a user from completing a task. Sites which contain even a single critical error will not conform to any level of WCAG 3.0 compliance.
- WCAG 1.0 was published in 1998, and was designed to help developers write accessible HTML.
- The W3C released the first working draft of WCAG 2.0 in 2001 and was designed to be applicable to all manner of competing web technologies including Flash. It was eventually published as a recommendation in 2008.
- WCAG 2.0 was republished as an ISO standard (ISO/IEC 40500) in 2012, making it easier for governments around the world to use it in law.
- In February 2017, the first draft of WCAG 2.1 was published, to address gaps in WCAG 2.0 concerning cognitive disabilities, low vision, and mobile devices. It was published in 2018.
- The first draft of WCAG 2.2 was published in February 2020 and is expected to become a recommendation this summer.
- WCAG 3.0 began life as “Project Silver” in 2016.
Now, on with the rest of the newsletter…
- Jeremy Keith describes his approach to building accessible ‘toggled content’: accordions, menus, modal dialogs and tabs.
- The first step is deciding whether the trigger should be a button or an anchor link. Jeremy bases this decision on the distance between the target and the trigger in the DOM:
- If in doubt, use a button, designed for general purpose activity. You probably don’t need to shift the focus.
- At this point there’ll be an
tabindex, and optional
focus(). You’ll also want a
aria-expanded="false"on the trigger and an
aria-hidden="true"on the target by default. When you activate your trigger, its attribute should update to
aria-expanded="true"and the target to
- Beginning in 2021, Apple will increase or decrease bonuses paid to its executives by a new ‘modifier’ worth up to 10% of their pay. It will be based on a performance evaluation with respect to Apple’s six core values: accessibility, education, environment, inclusion and diversity, privacy and security, and supplier responsibility.
- Apple doesn’t elaborate on how it will evaluate performance against these values, but it’s an interesting incentive and an example of what what some organisations are doing to maintain or improve the accessibility of their products, policies and services.
- IE11 was introduced in 2013 for Windows 7 and 8. Microsoft dropped support for IE11 in November 2020, but continues to provide security updates. Microsoft Edge replaced IE11 in 2015.
- IE11 accounts for around 1.4 – 2.5% of global site traffic, but the figure is higher amongst assistive technology (AT) users: as of 2019, 12.5% of screen reader users use IE11 (mostly with JAWS).
- Some ATs are still recommending pairing with IE11, though usually suggest an alternative too. For example, Dragon NaturallySpeaking recommends IE11 or Chrome.
- IE11 has a number of accessibility features, most of which are also offered by competing browsers (including Edge). One feature IE11 has, that Edge does not have, is the ability to natively override the fonts used in web pages, and also to add custom stylesheets. There are, however, extensions available that bridge the gap.
- Hassell Inclusion have tested JAWS v18 and Dragon NaturallySpeaking v14 on IE11 and other modern browsers. Where IE11 and Chrome worked as expected for both technologies, JAWS with Edge wouldn’t read out error messages linked to input fields with
aria-describedby, and Dragon found it difficult to follow links or moving between browser tabs.
- In conclusion, Hassell Inclusion currently recommend that websites continue to support IE11, until Edge improves its offering for AT users. This is also in line with GOV.UK recommendations.
I’ve seen a lot of social media hype around the improved accessibility of the new White House website. So I read a couple of articles to find out more:
- This article looks at some of the new features of whitehouse.gov. There’s a high contrast dark mode, and a toggle for increasing the global font size. The team behind it have also worked hard to make the site load fast, [and were even responsive to feedback from our own Matt Hobbs]. Jenny Lay-Flurrie, Chief Accessibility Officer at Microsoft, reviewed the site for accessibility and found no issues, though more can always be done, such as adding sign language to videos.
- Karl Groves does some navel-gazing at what the Biden Presidency might mean for accessibility more widely. Currently, 20 to 40 ADA (Americans with Disabilities Act) lawsuits are filed in US Federal Courts every day for accessibility violations on websites and mobile apps. Many, Karl argues, are opportunistic in nature.
- What muddies the waters further is that there’s no official standard for ADA compliance. In practice, settlements or judgements mostly measure against WCAG 2.0/2.1 at AA level, but Karl expects Biden’s administration to clarify the technical requirements for ADA (after – he says – the Obama administration deferred it). He also expects further momentum around Project Civic Access.
In other news…
- Amy Cesal guides us through the W3C guidelines for alt text for complex images. I actually learned a lot from this article:
- There’s a
longdescattribute for images, which can refer to other areas of the page. E.g.
<img alt="Short description" longdesc="#desc" /><div id="desc">Long description goes here</div>.
- Screen readers read alt text linearly, meaning they can’t go back a word if they missed something – so keep it short.
- Supplement with a link to the raw data, so curious readers can access the data in their preferred program. But don’t put the link in the alt text – it needs to be clickable.
- Alt text for charts should generally follow the pattern
[CHART TYPE] of [TYPE OF DATA] where [REASON FOR CHART]. For example, “Line graph of number of bananas sold per day in the last year where the winter months have more banana sales”.
- Finally, Amy describes how to add alt text on popular platforms such as Twitter, Medium, Microsoft Office and Instagram (which I didn’t know supported alt!).
- An article by World Eye Cancer Hope, from October 2020, which I’ve been meaning to read for a while. It contains lots of handy do’s and don’t’s:
- Do ask if they want assistance, and how they’d like it (e.g. “Would you like to take my arm?”). Do describe your surroundings, e.g. “We’re about to go up some steps”, or “Attendees of this event are standing in small clusters near the buffet table”.
- Don’t fill glasses or mugs to the brim. Don’t seat them at a table when everybody else is standing. Don’t limit the options you give because you think explaining all the options will take too long. Don’t manhandle, and don’t distract Guide Dogs.
- The Go FlyEase trainers require no hands to put on, thanks to their hinged kickstand design. You simply press down the heel of one foot with the other, and step out of the shoe (see gif). You can read more details on how the mechanism works, or watch the video about its design.
- The shoe will retail at $120, and is available from 15th Feb on an invite-only basis for Nike members. It will be made available to the public later this year.
- It was inspired by Matthew Walzer, who wrote a letter to Nike in 2012, at the age of 16. Matthew, who has cerebral palsy, has limited flexibility in one of his hands and found it impossible to tie his shoelaces, so appealed to Nike to help.
- Matthew is happy with the result, noting that it embodies the concept of “universal design”. Anyone can wear the shoes: they’re not just marketed as an accessibility feature. Everyone can benefit.
- This story was shared by subscriber Nick Levinson – thanks Nick!
- I’ve just heard about this product by AccessibleApps, which fills in CAPTCHA forms for you. For the uninitiated, CAPTCHAs are those anti-bot questions which try to make you prove you’re human by, for example, showing you a garbled image and making you type out the letter and number sequence contained within it.
- CAPTCHA Be Gone is an extension for Chrome, Firefox and IE, aimed at visually impaired and deafblind users who find it difficult or impossible to complete any form which has a CAPTCHA.
- Listen to a demo of it working: it’s slow (taking around 15 seconds), but seems to work. It’s not free though, costing $3.50 per month. There’s a seemingly impartial review which is positive about its price and effectiveness.
- It’s great that this is a solution to a real problem faced by users. But it raises two points from me:
- If a browser extension can solve a CAPTCHA, what’s the point of having a CAPTCHA in the first place?
- Having a disability already comes with a price tag; it’s unfair that these users need to pay for workarounds just for basic website access.
- Hopefully the web can move on from frustrating CAPTCHAs in favour of more accessible alternatives.
I’d like to end with a shout-out to Jack McElaney’s excellent newsletter, Accessibility in the News, which is packed with content every week. It’s heavily skewed towards American news, but there’s an international section too, and I look forward to receiving it every Friday.
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.