Designing web page layouts for screen readers
benrobertson.io
benrobertson.io
1. Put role="main" on the element that contains the main content of the page.
2. Make sure your headings are semantic (h1, h2, etc.), not just visual (e.g. divs or paragraphs with certain font sizes).
The rest is nice, but much less important IMO.
Don't get me wrong, I'm glad to see an article on this subject on the front page, and it's very thorough. I just thought a very brief summary of the essentials might be helpful.
On the other hand, nav and banner (among others) are types of landmarks. It's nice to have those, but the one that screen reader users will want all the time is main.
The tricky thing about when you're talking about screen readers is that you now have to take into account browser support AND screen reader support, which can sometimes multiply the amount of test cases for things.
If you have access to a Mac, VoiceOver is built-in and supposed to be a pretty good screen reader, though it's not as popular as the expensive ones.
If you want to check for ARIA correctness, there are plugins for Chrome and Firefox that will check your pages and show you things you did right, and things you did wrong.
Some are better than others, however. And all the ones I've seen give false positives to perfectly valid conventions. But it's better than not knowing if you're making progress.
Yeah, that’s what I used. I haven’t had anyone actually try to use my website, though.
Often there's substantial overlap between improving accessibility and helping "power users".
Sometimes that overlap can help convince managers to spend more time on these kinds of features.
(Unless maybe your whole model is herding people to ads or "promoted" stuff.)
This was actually the easiest way to sell a management on some of the time we were spending making our latest project accessible. We had time allotted for power user workflows. If you’re implementing keyboard shortcuts there is likely something about that particular type of action in WCAG.
Of course theirs more to it than that. One of the hardest things was coming up with a good strategy for handling hover/focus/active states that didn’t look gaudy to management. The new :focus-visible selector can help where it’s supported, but getting our designed to think about these additional states when designing components helped a lot.
I often wonder if it would be easier to push out a second, accessibility-friendly version of the site on a subdomain. Something like acc.example.com that screen readers and other accessibility tools would check for when they access example.com.
We used to do this back in the WAP days: wap.example.com, and even in the early iPhone days with i.example.com, mobile.example.com, or m.example.com.
I believe it would save time on some projects.
While it may sound like a good idea, it literally violates the U.S. Air Carrier Access Act and SAS (the airline) was recently fined for doing exactly what you describe[1].
This solution may also create a situation where the accessible website becomes a "second class citizen" in terms of content because managers are not willing to allocate resources to improving the dedicated accessibility-friendly version. I argue it's much better to make a11y a part of the specification process just like we did with the responsive web when we abandoned WAP.
Getting the data is easier nowadays than in the past. E.g. https://www.census.gov/newsroom/releases/archives/miscellane... and http://www.pewresearch.org/fact-tank/2017/04/07/disabled-ame...
Can you be sure that the separate accessible version would be kept up to date with the mainstream version, and have all the same functionality? "Separate but equal" didn't work when applied to racial segregation, and accessibility advocates tend to discourage it as well.
You can try to sway your boss by explaining the second "accessibility-friendly" version is needed for a different set of target audience.
http://cryptomarketplot.com/accessible-index.html is made both for geeks who use terminal browsers like links, and people who depend on screen readers and could not use the graphs.
Seriously, try the page with elinks inside xterm to even get the colored trend arrows!
Isn't this essentially what AMP is? It's not limited to Google subdomains AFAICT, e.g. apparently Cloudflare can also host cached AMP content.
Thanks so much for sharing, and I'm glad to see some good discussion going on here! I'd love to answer any other questions people might have.
Also, for those newer to the accessibility space, I have a free email course that covers 10 common accessibility mistakes, how to fix them, and the accessibility principles behind them. Here is a link to the course: https://benrobertson.io/courses/common-accessibility-mistake...
If you want see the material but not sign up for an email thing, I have a talk recorded covering the same material: https://benrobertson.io/accessibility/common-accessibility-m...
Like I said, happy to answer any accessibility questions people might have!
What it largely boils down to, from a legal (not necessarily a moral) standpoint is the balance between "reasonable accommodations" for the disabled and "undue burden" on the business to implement accommodations.
When you're small and scrappy, or dealing with some domain that absolutely demands unimpared vision to use, you can argue that accessibility features would place some undue burden on the business to implement. As you grow larger as a company, and the very likely probability that what you do doesn't actually absolutely need unimpared vision, the more likely a judge or jury would be to find that accessibility features would represent a "reasonable accommodation" that you must fulfill, and likely must pay a lot of money for failing to have done so.
SaaS applications almost invariably can be made accessible, since they are, by definition, provided as a service over http or some API. Whether you must make them accessible is for a court to decide; whether you should is almost always a yes. It's generally cheaper up front than paying the legal cost later on, and your users will appreciate it. You may even end up hiring a blind engineer, who would most certainly appreciate it.
The total decoupling of visual presentation from content structure is such an important factor in these matters.
One bit of styling best avoided because it creates confusion for users operating a site by keyboard is the "order" property used with Flexbox and CSS Grid, it will change the visual order of elements but not their order in the DOM.
Thanks for posting!