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.
As far as I'm aware, article and section don't do anything for screen readers. Someone please correct me if I'm wrong on that.
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.
I believe `<main>` is not supported in IE11 - here is a resource that you can use to check HTML5 accessibility compatibility: https://www.html5accessibility.com/
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.
Usually, you can get a lot of accessibility “for free” if you try not to stray too far from how things are supposed to be used. The more you start getting clever and abusing components, the more likely your layout is impossible to navigate by screen readers and similar assistive software. My website makes heavy use of semantic tags, and doesn’t have an overly complex layout, so I think it does pretty well in a screen reader (though, I have not actually asked anyone to test this).
I think it does pretty well in a screen reader (though, I have not actually asked anyone to test this).
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, I totally agree with this. Staying as semantic as possible is the best way to go. With some very judicial use of ARIA I think you can improve the experience a little.
> Now an assistive technology user has an equal (and maybe even better) conceptual map of the content and actions they can take on this website compared to a non-assistive technology user. They can get a quick overview of everything on the site, easily navigate to the section of the page they want, and quickly find what they are looking for.
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.)
The keyboard navigation that is required to support the WCAG spec is greatly appreciated by me, even though I am fully sighted and don’t use a screen reader.
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.
My biggest frustration with building accessible web sites is that what looks good to a boss, or manager, or marketing department is not always what works well for building a semantic, accessible web page. It's often a struggle to make the two work together, especially years after a site is completed and new features have to be bolted on because of the whims of someone higher in the food chain.
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.
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.
Not only do you run the risk of offending users with disabilities by forcing a separate experience, this also creates a separate code base to maintain and often developers forget to update text-only versions. I've worked in the accessibility space for years and this concept is an idea of the past and likely to generate a lawsuit. Accessibility lawsuits are popping up left and right in the public sector across every business vertical and I would strongly advise against this.
I'm one of those in the marketing department and there's a compelling case to be made for making sites accessible. If you're running into obstacles from management or marketing it's likely because they don't have a grasp of the numbers.
> I often wonder if it would be easier to push out a second, accessibility-friendly version of the site
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.
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...
I'm a software developer. I like the idea of accessible web interfaces, but I have, and probably always will, work on user interfaces that have a relatively small user base compared to large sites like the Washington Post or Google. (I've worked for SaaS companies for the last 15 years.) Someone in another thread mentioned legal requirements regarding accessibility for US air carriers; are there any general requirements for software accessibility? (Software used as part of a job, in particular.) Otherwise I don't think that I'd be able to convince my management that this was worth worrying about, unfortunately.
I'm not aware of any general requirements for software, aside from what the ADA covers and case law. The most common example I know of is Target; IIRC it was among the first to bridge the real world and the internet in terms of legal requirements for accessibility. [0]
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.
This is all solid advice imho - and a useful digression from the usual accessibility story that just focuses on making content legible to partially sighted people.
The total decoupling of visual presentation from content structure is such an important factor in these matters.
Very timely! I've been working on making a site accessible to screen readers and people who navigate via the command line. One thing I have been wondering is how often people who use screen readers are navigating with CSS/styles turned off. It seems like screen readers would work better without CSS (for example on semantically correct elements that are getting decorated with CSS), but I don't know if that is common or not. Anyone have any experience with that?
The styling doesn't change the semantics for the screen reader. Most people who use a screen reader also have some vision so disabling a site's CSS entirely would remove meaning that is, intentionally or not, conveyed by the styling. It's more common to modify a site's styling to be more usable, though that's not a reason to skip making a site's styling more accessible to begin with by having sufficient color contrast, large enough text, etc.
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.
This is a really well written article. It’s a topic on which I’ve had a hard time tracking down clear, concise information. So many articles are either fluff or way too technical. This is just right.
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.