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.
- Blog post by Adam Silver, explaining why splitting inputs can be problematic. A technique often used for credit card numbers and bank sort-codes, I’ve often found such forms quite slick, but hadn’t considered some of their accessibility downsides:
- It can be difficult to correct mistakes if the form auto-focuses the next input in the sequence.
- Each input is difficult to label meaningfully. The label is often hidden from sighted users, if provided at all, and makes for a noisy screen reader experience.
- Instead, Adam encourages us to allow free-form text and to be forgiving of extra spaces and dashes in inputs. The exception is dates, where multiple inputs should be used, to clarify which portion of the date is the month and which is the day (as this varies around the world).
- A Daily Express article from last summer. Bioengineers at the University of California have developed a glove that can translate sign language into speech in real-time, using an accompanying smartphone app.
- The glove has thin sensors running to the fingertips, which can detect motions. The smartphone app uses a custom machine learning algorithm to convert the gestures into letters, numbers and words, and can recognise 660 signs. It translates at a speed of one word per second, with an accuracy rate of 98.63%.
- The glove has its critics. Gabrielle Hodge, a deaf researcher at University College London, says: “there is nothing wrong with [sign language as a] form of communication” and that the technology is “redundant”, due to deaf signers already making extensive use of text-to-speech software.
- The Readability Group is a collection of experts in design and accessibility. Their mission is to “optimise typographic accessibility by providing expert advice based on data, not anecdote”. Essentially, they want to gather real user feedback on the readability of typography.
- Please take around twenty minutes of time to contribute to the “Readability survey”, which has been nearly 2 years in development!
- Article exploring the pros and cons of infinite scroll. The pros were simply “seamless mobile scrolling” and “serendipitous browsing”. The cons were numerous:
- Could contribute to social media addiction.
- Might make sidebars and other content inaccessible to assistive technology users.
- Makes footers impossible to reach.
- Causes users to lose their place (especially when hitting the ‘Back’ button).
- Slows down users who have specific goals (e.g. wanting to jump to a letter midway through the alphabet).
- Tips to improve infinite scroll implementations:
- Don’t place content below the infinite scroll.
- Code in some logic to allow ‘Back’ interactions to keep their place.
- Let user skip to particular numbers/letters.
- Ensure it works for keyboard users.
- A very popular article among a11y newsletters at the moment. Eric Bailey reminds us that WCAG is a standard, that sets “objective criteria for what is and is not accessible”. In other words, you might hate the design of a website, but it might conform to all WCAG criteria. Don’t creatively reinterpret what a Service Criterion says to fit your agenda.
- As a designer, you can appeal to a product’s usability, giving subjective feedback grounded in objective origins. But in an auditing context, you have to kill your ego and only point out failures that map to WCAG rules.
- Eric says you should think like a lawyer: every call you make might have to be defended in a court of law [it’s worth noting that this article is written from an American point of view]. That is to say, “stay in your lane”, by sticking to established, legally accepted parameters, i.e. WCAG.
- News organisation ProPublica ‘translated’ one of their articles into plain language, in an effort to be more accessible to people with intellectual/developmental disabilities.
- Here’s the original article: People with Developmental Disabilities Were Promised Help. Instead, They Face Delays and Denials.
- And here’s the plain text version: Arizona Promised to Help People With Developmental Disabilities. But Some Had to Wait a Long Time. Some Did Not Get Help at All.
- It’s fascinating to read the articles side by side and see how they compare. The plain language version simplifies sentences, writes in active voice, and uses bullet points for lists.
- Some of these seem fairly obvious, but others less so. With respect to autism, “high or low functioning” is an ableist term I hadn’t considered. ‘Differently abled’ and ‘special needs’ are also poor euphemisms for the term ‘disabled’. ‘Tone deaf’ and ‘blind spot’ are also terms in common usage, but which harmfully link deafness/blindness with ignorance.
- The other phrases this article considers ableist are ‘imbecile’, ‘crippled’, ‘spastic’, ‘lame’, ‘suffering’ (as in “suffering from [disability]”), ‘wheelchair bound’ (in reality, many wheelchair users find their wheelchairs liberating) and finally, a saying I hadn’t heard before: “See the Able, Not the Label”.
- Article by Yakim van Zuijlen, describing how to use VoiceOver on a Mac to test your website. It’s aimed at beginners, but goes into quite a lot of detail, including how to find items by type (e.g. blockquote). There are some beautiful, clear illustrations throughout the article, showing which keys to press to trigger shortcuts, or how elements in the browser are grouped together by VoiceOver.
- A listicle by Twan Mulder, which I wasn’t expecting to learn anything from – but then I learned something from the very first point! It was this:
- You often need to denote the ‘current’ page in navigation, and you see this in the wild with
class="active"or similar in the markup. Instead, it should use
aria-current="page", to tell screen readers this is a link to the same page they’re already on.
- The other tips are to use
aria-hiddento hide decorative separators between links; add visually hidden text to your icon links; apply ARIA markup to your
<div>if you insist on not using a
<button>; and, somewhat obviously, provide
alttext for your images.
- Microsoft software engineer Swetha Machanavajhala is deaf and relies on lip-reading. Whenever she Skyped her parents, she had to ask them to turn the lights off behind them so that she could more easily focus on their faces.
- She wondered if technology could solve this problem for her, so worked with Microsoft to build a background-blurring feature for Microsoft Teams and Skype (it’s not clear in the article exactly how Swetha achieved this). This feature has a useful side-effect as being a privacy tool to help users hide their backgrounds during calls.
- Thanks to Lee Goudie for pointing me towards this excellent example of Universal Design!
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.