To new developers, learning that you can put content offscreen is a pretty handy tool for accessibility. CSS allows you to add content to your pages that screen readers will read aloud without having to jam everything into an image alt attribute (it’s also helpful for SEO). For example, what if you’re building an interactive annual report with a bunch of highly-designed tabular data? One solution is to embed an image for a table and put the live data offscreen. Pretty freaking cool.
- The presence of inaccessible Flash content
- CAPTCHA – images presenting text used to verify that you are a human user
- Links or buttons that do not make sense
- Images with missing or improper descriptions (alt text)
- Screens or parts of screens that change unexpectedly
- Complex or difficult forms
- Lack of keyboard accessibility
- Missing or improper headings
- Too many links or navigation items
- Complex data tables
- Inaccessible or missing search functionality
- Lack of “skip to main content” or “skip navigation” links
Pictured: Problematic Items from the WebAIM Screen Reader Survey (opens in a new window) with data offscreen and topics we discussed highlighted in secondary color
WHAT I’M THINKING ABOUT NOW
I’m a big advocate for offscreen text, especially for links that open in new windows. A valid question was brought up in class: how would you manage all of your accessibility content when localizing a site? Hopefully you could use templating and content files (like JSON) to let the computer do the heavy lifting for you. Without “seeing” all the content you’re putting into your pages, however, it might cause mistakes–especially for a development team new to the process of building accessible websites. Definitely something to think about.
Headings & HTML5
How do you explain the importance of headings & screen readers to new developers, and then turn around and explain how different/weird they can be in HTML5? It’s a difficult topic. At their most basic level, headings add a semantic outline to your documents. Screen readers also use them to navigate, so they’re an important accessibility tool. But if you’ve ever had to support old versions of JAWS while pushing ahead with new technology, you might be aware of the bugs (opens in a new window) and lack of support of not only the new heading algorithm, but also basic HTML5 tag support (opens in a new window). I’ll continue to refine my explanation of this topic since it’s so important!
Ever since Angelina Fabbro’s talk on the ShadowDom (opens in a new window) at the first CascadiaJS, I’ve had questions about the ShadowDom & accessibility. This time around, Soledad Penades’ talk about Web Components and Audio (opens in a new window) got me thinking again about accessibility. For example: how does this new technology work with a keyboard? I’ve heard there is ARIA support (opens in a new window), but I’m also thinking it’s the perfect time to do some research (and maybe even make some impact on a new standard!).
I’m excited to see where this all leads!