Web Accessibility slides

[zdashamber]

I'm going to give a five-minute presentation tomorrow evening on basic web accessibility (what to do re: designing and developing a website)... Here are the slides: https://slides.com/madelinebernard/webaccessibility

I'm interested in taking feedback on it, if you have any!

Comments

[lilysea]

I haven't read it, but have you talked about readability for people who are red/green colourblind?

[invaderjim]

I have no experience on this topic, and I found it informative and concise. Thanks for sharing.

[deborah]

Nice presentation, though maybe it could use a little more structure. One way to think about it is, if you were writing all of it down as a single web page, what would the h1-h6 heading elements be? I always encourage people to think of headings as their page outline, since that's what makes them most useful to screen reader users. What's the outline of this piece?

In five minutes, you can't say much, and your best bet might be to talk about your paper or digital handout, and where people can find more information.

Some vita points:

1. "Accessibility" does not mean "screen reader accessibility". A good set of Web Personas is a great way of understanding this. There's a great set of disability personas at the W3C.


2. This means you must remember keyboard accessibility. In the modern web, this means
   • Use native HTML whenever possible (your slide 3 alludes to this but it's vitally important)
   • tabindex (should always be 0 or -1, never positive)
   • In the JS, keyboard events for everywhere there's a click or hover event.
   • WAI-ARIA roles


3. The HTML title attribute is almost never useful


4. Writing your own keyboard shortcuts in JS does not add accessibility in most cases. If you have them, document them, make that help file easy to find, and make a way to turn them off. Most users of AT already have any number of keyboard shortcuts and site-specific ones probably conflict.


5. Color contrast, labelled controls, and high-visibility indicators of keyboard focus are vital. Usability for all users is enhanced by these, for what it's worth. Misused minimalist design drives users away.


6. <abbr> actually doesn't make that big a difference for most users. Just like sighted users, screen reader users will recognize "NASA" more than "National Aeronautics and Space Administration".


7. Modal pop-up windows are usually a disaster. Make them correctly


8. WebAIM surveys are up to survey 6


9. The two most important things to say about WAI-ARIA are (1) that it's one of the vital tools necessary to make the modern, dynamic web accessible, and (2) "the first rule of using WAI-ARIA is: Don’t use it unless you absolutely have to! The less WAI-ARIA you have, and the more you can count on using native HTML widgets, the better"


10. There's a lot of misinformation out there about web accessibility; web search wisely. Some resources to trust:
    
    
    • The W3C: http://www.w3.org/WAI/
    
    
    • Marco Zehe: https://www.marcozehe.de/
    
    
    • The Paciello Group: https://www.paciellogroup.com/blog/
    
    
    • WebAIM; http://webaim.org/
    
    
    • WebAIM mailing list: http://webaim.org/discussion/

[zdashamber]

Thanks so much for the notes!

About abbr, I was wondering if, for instance, a screen reader would say "eyoc" instead of EEOC (Equal Employment Opportunity Commission)... Or some of the other, not so pronounceable acronyms. But yes, sounds like I should just find another example of "uncommon but helpful" HTML tags to use in that point.

Loved the WebAIM surveys, the 2012 #4 one was the most recent one I saw with a "these are the most annoying things" chart.

The Personas link is great, thanks! More directly actionable than the Alphabet of Disability I linked.

[adrian_turtle]

Who is your audience? Are you speaking to developers who might otherwise think accessibility doesn't matter? Or developers who think accessibility might be a nice feature if it wasn't so hard to implement? Or developers who are really careful about being accessible to one users with a particular disability and need to understand that isn't "universal" design? Or frustrated users with disabilities (like us) who use websites but may or may not design them? Or managers who set specifications for company websites?

The jargon page doesn't seem to add much, for such a short presentation. Are you defining the terms because they are used in the references you point people to, on the last slide? If they're defined on those websites, you don't need to define them before sending people there.

I like the graphic about what causes the most accessibility problems. I'm not a web designer, but I'd find it helpful if there was a more explicit connection between that and the other information. Doing this html thingee avoids that problem people complain about. Maybe it's all obvious to people who work in the field. Some of it is stuff I can make sense of, but it would be a lot clearer if it were organized as "this is what's a problem for screen readers" and "that's a problem for keyboard accessibility" and "this other thing is a problem for photosensitivity."

[zdashamber]

I'm speaking to 70ish students of a Javascript bootcamp, most of whom are just now learning a lot about the web. My hope is to get the idea of building accessibly planted before they start getting set in their ways.

Great point about the jargon slide, thanks, and about the organizational issues!

I liked the graphic about "what is most annoying" also, I haven't seen other surveys of the sort.