How to create content that works well with screen readers(accessibility.blog.gov.uk)
accessibility.blog.gov.uk
How to create content that works well with screen readers
https://accessibility.blog.gov.uk/2017/02/08/advice-for-creating-content-that-works-well-with-screen-readers/
12 comments
I’ve been lucky enough to work with Léonie and would echo that she’s a massive resource of practical accessibility knowledge. The blog post above was on HN and generated some discussion: https://news.ycombinator.com/item?id=10324480
As someone with low vision, every time I try to read a long article (like this one) I have to make a text color white, a background color black, and text size bigger to make it easier to read. In lucky cases, Firefox's Reader View works rather well. (Although I needed to write a user style so that the contrast would be higher) In cases where Reader View doesn't work or I need to read other parts of a page, I have to write a user CSS with Stylish. It's so frustrating to do this for numerous times. My routine is like this: First, test if `body {color: white !important; background: black !important;}` works. If not, I would right click on a text, select Inspect Element, and look for the CSS rules affecting colors, after which I would write a user CSS to overwrite the rules found. Occasionally the CSS of a page is complicated and it would take me a long time to figure out which CSS rule I should overwrite.
Having done this for countless times, I started thinking as to why I need to do this (obviously given my condition). Why do I have to write a user CSS? Because like Firefox's Reader View, computers could do heuristics at best and when they fail a human has to tell computers which part of a page is text. Why does someone have to figure it out? Because HTML does not contain that information (except for pages that adapt HTML5 semantic tags).
I wish HTML were a bit more restrictive and a page couldn't be designed arbitrarily. For example, if the "Hyper Text" were a lightweight markup language like Markdown or reStructuredText rather than HTML, my life would have been much easier. Some people might say it would be too restrictive. But I have to point out that the standard way of transmitting text, which is by encoding a character to a code point with some character set, is already restrictive when compared with handwriting. We abandoned the freedom to draw characters arbitrarily for communicating machine- (and thereby visually-impaired-) friendly. Because we use character codes to transfer text, we can use any font we like almost everywhere with little effort. I just want the same thing to have happened in the Web.
Having done this for countless times, I started thinking as to why I need to do this (obviously given my condition). Why do I have to write a user CSS? Because like Firefox's Reader View, computers could do heuristics at best and when they fail a human has to tell computers which part of a page is text. Why does someone have to figure it out? Because HTML does not contain that information (except for pages that adapt HTML5 semantic tags).
I wish HTML were a bit more restrictive and a page couldn't be designed arbitrarily. For example, if the "Hyper Text" were a lightweight markup language like Markdown or reStructuredText rather than HTML, my life would have been much easier. Some people might say it would be too restrictive. But I have to point out that the standard way of transmitting text, which is by encoding a character to a code point with some character set, is already restrictive when compared with handwriting. We abandoned the freedom to draw characters arbitrarily for communicating machine- (and thereby visually-impaired-) friendly. Because we use character codes to transfer text, we can use any font we like almost everywhere with little effort. I just want the same thing to have happened in the Web.
Until version 12, the Opera web browser had a menu with a big list of CSS override styles that worked like Firefox's Reader View. Some were for page development/debugging, some emulated small screen devices, and a lot were there to improve readability. I have good vision and used the Opera CSS overrides and still use Firefox Reader View frequently because many web pages are poorly accessible even for people without disabilities. When Opera went to the WebKit rendering engine the CSS overrides were removed. I still miss them.
I can't remember the last time firefox 'reader view' didn't work for me.
Do you really need to go down those roads this often(serious)?
I'm really not trying to call you on anything; but would you mind sharing some example links where it don't work so we can fix it?
I can't find a single example which doesn't work currently. Things have really improved recently.
What I routinely can't or maybe just won't read on ff reader view thigh are forums/hn comments.
Do you really need to go down those roads this often(serious)?
I'm really not trying to call you on anything; but would you mind sharing some example links where it don't work so we can fix it?
I can't find a single example which doesn't work currently. Things have really improved recently.
What I routinely can't or maybe just won't read on ff reader view thigh are forums/hn comments.
You might like the "Dark Background and Light Text" add-on for Firefox:
https://addons.mozilla.org/en-US/firefox/addon/dark-backgrou...
Unlike Reader View, it lets you pick any combination of colors that you like.
https://addons.mozilla.org/en-US/firefox/addon/dark-backgrou...
Unlike Reader View, it lets you pick any combination of colors that you like.
As someone with low vision myself, I appreciate your point. However, have you considered just using a screen reader to read any significant amount of prose? That's what I've done for the past 12 years or so. I still use my eyes when reading and writing code, though.
The text-to-speech engine that I normally use with my screen reader on my PC, ETI-Eloquence, is surprisingly good at choosing the correct pronunciation in ambiguous cases. It got the handful of examples that she mentioned correct. I'm sure it's not perfect at handling these cases, but it does try. And that's a synthesizer that was implemented in the mid to late 90s and abandoned in the early to mid 2000s. I'm sure they could do better today.
If you're looking for a quick summary about web accessibility best practices, my team put together a web accessibility guide: http://web-accessibility.carnegiemuseums.org/.
Is <abbr> etc. Used by screen readers? I kind of thought that was the point...
look at it with a terminal based browser like lynx.
> So the best answer seems to be: don't write content that works specifically for screen readers, write content that works well for everyone. Use correct punctuation, spelling and grammar, use standard conventions for acronyms and abbreviations, and use words that are appropriate for your audience.
http://tink.uk/losing-sight/