Your weekly frequent11y newsletter, brought to you by @ChrisBAshton:
- Accessibility Statements Show Commitment to all Site Users
- (Article from 2013, updated this month). Describes an “Accessibility Statement” (formerly “Accessibility Information Page”) as being a place to list an active phone number & email address, linked to from all pages, and with “details about the organization’s web accessibility policy”. The article links to the Accessibility Statements of some big companies, such as eBay’s, which describes its “skip link” feature and suggested screen reader commands (though I’d imagine users who need to do that know how to do it already). It also links to a list of companies’ accessibility Twitter accounts, most of which are worth a follow.
- Aside: it’s not linked in this article, but the GOV.UK accessibility statement is the best I’ve seen (I may be biased!). It sets expectations like “[you should be able to] zoom in up to 300% without problems”, as well as outlining some of the accessibility issues we haven’t fixed yet and how people can request an accessible format. (In practice, I think most sites seem to use their Accessibility Statement as a fluffy PR page along the lines of “accessibility is important to us” with little extra substance).
- Travelers with disabilities learn what it feels like to fly – without leaving LAX
- Alaska Airlines and Los Angeles International Airport teamed up in June to allow families to board a ‘fake flight’. The event, dubbed ‘Ability to Fly’, was an opportunity for families with children who struggle with sensory processing and noise, to give them a trial run of air travel without the pressure of a real, busy flight. Families went through the entire check-in, security screening and the boarding process, before the plane taxied to LAX’s remote gates and then returned to the gate. It’s given several families the confidence to come back and do it for real.
- Consistently Inconsistent: When the Most Accessible Experience is Different for Each User
- A client requested that their ‘select menu’ should sound identical in every screen reader. Author @ericwbailey points out that, counter-intuitively, implementing a bespoke solution would break ‘external consistency’ and worsen the experience for everyone, as users would no longer have the learned predictability of how to interact with your page. The result was to push back on the request and highlight that screen reader differences are intentional, and also that using native elements requires much less testing. Worth checking this out just to hear how differently VoiceOver, NVDA and JAWS read out the contents of a
<select>element (the article contains audio samples of each, conveniently listed next to each other).
- A client requested that their ‘select menu’ should sound identical in every screen reader. Author @ericwbailey points out that, counter-intuitively, implementing a bespoke solution would break ‘external consistency’ and worsen the experience for everyone, as users would no longer have the learned predictability of how to interact with your page. The result was to push back on the request and highlight that screen reader differences are intentional, and also that using native elements requires much less testing. Worth checking this out just to hear how differently VoiceOver, NVDA and JAWS read out the contents of a
- The Front-End Tooling Survey 2019 – Results (specifically question 25)
- Take these results with a pinch of salt – only 3005 developers filled in the survey, sourced from places like Twitter and LinkedIn. Asked ‘Which of these accessibility tools do you use to test your sites/applications?’ and presented with options, 63% of participants said they don’t use any (the next most popular option was colour contrast checker, at 22%, then screen reader at 15%). This doesn’t look great; for comparison, when asked which tools they use to test their performance, 52% said they use Lighthouse, vs 32% who don’t use any. But we’re missing context. It’s possible these devs work at companies who have testers that do the screen reader testing, whereas something like performance might be considered the developer’s remit. Or that Lighthouse is built into their CI process, but they don’t really ‘use’ it themselves. I’d like to see a bigger sample size with reworded questions that give us a better idea of developers’ situations.
- Website Accessibility and Buying Power of Persons with Disabilities
- A slightly controversial article from 2011, part of a business case for web accessibility series of blog posts by Karl Groves. Accessibility advocates say that making your site accessible makes it more profitable, as it opens it up to people who would otherwise be unable to purchase from you. This is true, but its impact can be exaggerated by including people whose disabilities don’t affect their ability to use the web, or who would never be able to use the web. Discarding these groups, Karl estimates that 7-10% of the US population truly rely on websites being accessible. He goes on to say that this group is “almost twice as likely to live in poverty”, and that without “heavy marketing” they are not going to know that your site is any more accessible than that of your competitors. In conclusion, accessibility for the sake of the “buying power of persons with disabilities” is not a very strong business case as it is unlikely to generate much income for your site. It’s worth reading the rest of his series which highlights stronger business cases for building accessible sites.
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.
