Designing web page layouts for screen readers
benrobertson.io
Designing web page layouts for screen readers
1–10 of 29 posts
Re: Designing web page layouts for screen readers
#2This 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.
Re: Designing web page layouts for screen readers
#3IMO, 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.
Re: Designing web page layouts for screen readers
#4> 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.)
Re: Designing web page layouts for screen readers
#5IMO, 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 brie…
It is indeed helpful. Thanks! I get often confused by the other semantic tags like article, section etc
Re: Designing web page layouts for screen readers
#6Usually, 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).
Re: Designing web page layouts for screen readers
#7My 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.
Re: Designing web page layouts for screen readers
#8Usually, 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…
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.
Re: Designing web page layouts for screen readers
#9Usually, 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…
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 wr…
> 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.
Re: Designing web page layouts for screen readers
#10> 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 helpin…
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.