Live data from Hacker News

Designing web page layouts for screen readers

benrobertson.io

11–20 of 29 posts

Re: Designing web page layouts for screen readers

#11

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 wo…

Small teams are better.

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!

Re: Designing web page layouts for screen readers

#12
post #5

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 brie…

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

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.

Re: Designing web page layouts for screen readers

#13

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 wo…

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

Re: Designing web page layouts for screen readers

#15

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 wo…

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

Re: Designing web page layouts for screen readers

#16
post #15

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 wo…

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-friend…

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.

Re: Designing web page layouts for screen readers

#17

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 wo…

> I often wonder if it would be easier to push out a second, accessibility-friendly version of the site on a subdomain

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.

Re: Designing web page layouts for screen readers

#18
post #5

Earlier quoted context omitted.

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

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.

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

Re: Designing web page layouts for screen readers

#19
post #18

Earlier quoted context omitted.

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.

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

These days they generally support the main element.

Re: Designing web page layouts for screen readers

#20
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...

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!

Post reply on HN