
Designing web page layouts for screen readers - fanf2
https://benrobertson.io/accessibility/designing-layouts-for-screen-readers
======
mwcampbell
IMO, the two most important things are:

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.

~~~
baxtr
It is indeed helpful. Thanks! I get often confused by the other semantic tags
like article, section etc

~~~
mwcampbell
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.

~~~
brlewis
Does it have to be role=main to support all screen readers, or these days do
they generally support [http://html5doctor.com/the-main-
element/](http://html5doctor.com/the-main-element/) ?

~~~
brobertson
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/](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.

------
saagarjha
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).

~~~
reaperducer
_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.

~~~
saagarjha
> 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.

Yeah, that’s what I used. I haven’t had anyone actually try to use my website,
though.

------
greghendershott
> 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.)

~~~
charrondev
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.

------
reaperducer
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.

I believe it would save time on some projects.

~~~
esphen
Be careful with this.

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.

[1]: [https://www.transportation.gov/briefing-
room/dot7418](https://www.transportation.gov/briefing-room/dot7418)

~~~
reaperducer
Interesting. I don't work in the airline space, but I wouldn't be surprised if
other sectors had similar laws. So I guess the suggestion is moot.

~~~
robmc_
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.

------
brobertson
Hey, author of the post here :)

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...](https://benrobertson.io/courses/common-accessibility-mistakes/)

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...](https://benrobertson.io/accessibility/common-
accessibility-mistakes-and-how-to-avoid-them)

Like I said, happy to answer any accessibility questions people might have!

~~~
sam_bishop
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.

~~~
zdragnar
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.

[0] [https://webaim.org/blog/target-lawsuit-
settled/](https://webaim.org/blog/target-lawsuit-settled/)

------
eponeponepon
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.

------
uxamanda
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?

~~~
extra88
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.

~~~
uxamanda
That makes sense, thanks for the reply. I hadn't thought about low vision
users using screen readers.

------
christophilus
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.

Thanks for posting!

