I recently attended a Refresh Baltimore event on Web Accessibility. The speaker, Reinhard Stebner, was amazing. Honest and humorous, he made a big impact on my perception of web design and development. He is also completely blind. He spent the first part of the presentation answering questions about his lifestyle; cracking great jokes and making us understand a situation that is almost unfathomable.
What makes a website both accessible and usable? Using the JAWS screen reader he showed us how another group of people see the world online. Moving through various government websites, we heard how a 508 compliant website sounds. We also saw that most of the time these sites lacked usability. Reinhard also broke down the MICA website; made primarily of lists, it was difficult to find the main content of the page.
Here are some great points I learned about coding for a screen reader:
Limit your links.
Before the reader moves through the website, it sizes it up and gives the listener and overview of the content. "150 links" seems overwhelming and a little daunting and is something to consider in your editing process. What is necessary? What is extraneous?
Headings are for structure, not font styling.
As visual designers, we often see code as something we can twist and manipulate in order to establish a visual dialogue. Yet if the site structure and design are not in sync, then the screen reader is unable to establish a hierarchy for the listener. For example, "News Headlines" is a H5 tag while the headline "A mischievous puppy was found trying to eat a giant rock" (true story from a minute ago) is a H2 tag.
Navigation should be made with divs and spans, not lists. I think everyone in the room scratched their heads when this was said. One of the first things you're taught about coding is how to structure a navigation and this is normally done with an unordered list. This list structure, however, is not conducive to the screen reader's logic. The span tag is not recognized by the screen reader, so it is one of the ways you can simplify your content for accessibility.
Display and visibility traits should come secondary to negative margins. If it's not on the screen, it's not going to be read. This varies depending on the screen reader you're using. It is best to have the necessary text, which may have been replaced by and image, visible to the screen reader to maintain the cascade logic.
Label all your graphics and images with an ALT attribute. This is something that is well known, but is still not always implemented during the coding process. He emphasized that accessibility shouldn't be an afterthought, but present throughout the planning and coding process.
Load order is king. The screen reader works with load order to convey content. If your header is loading last, but your CSS is popping it up to the top of the page you're only creating a visual solution that will not work for a screen reader.
Overall, I'm excited that I was able to have this opportunity and look forward to the ones that follow. I may introduce myself as a web newbie, but I hope to continue to learn from experts and the Baltimore web community.
It would be interesting to dig a little more into why unordered lists are bad. You say they are "not conducive to the screen reader's logic", but how so? It seems like "skip" links are more appropriate than divs and spans. At least lists provide *some* semantics and provide an easy way to style. Great article.
ReplyDeleteHey, its cool as a newbie you're takinhng on board accessibility as a part of the prcess, rather than a later bolt on... but...
ReplyDeleteI too can't see why unordered lists are "not conducive to the screen reader's logic"? I'm suspicious that its just one person's quirky preferecne, that may be a hinderence for most. I've asked two screen reader users here where I work, and both prefer a list (which announces the number of menu items, and informs you when you leave the list).
Also, the statement "If it's not on the screen, it's not going to be read. This varies depending on the screen reader you're using." seems dubious to me. As far as I know most if not all screen readers will read offscreen content... screen readers are accessing a version of the dom, and just arn't referring to the visible webpage, and would have to make a judgement what was visible or not, which doesn't seem very likely...
Sorry if I sound negative - - - I've no reason to doubt Reinhard Stebner is an experienced accessibility tester - I just don't understand his reasoning?