zdashamber: painting - a frog wearing a bandanna (Default)
Madeline the Edifying ([personal profile] zdashamber) wrote in [community profile] accessibility_fail2015-12-29 08:39 am
Entry tags:

Web Accessibility slides

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!
lilysea: Serious (Default)

[personal profile] lilysea 2015-12-29 04:47 pm (UTC)(link)
I haven't read it, but have you talked about readability for people who are red/green colourblind?
invaderjim: orange and yellow sunflower (Default)

[personal profile] invaderjim 2015-12-29 05:34 pm (UTC)(link)
I have no experience on this topic, and I found it informative and concise. Thanks for sharing.
deborah: the Library of Congress cataloging numbers for children's literature, technology, and library science (Default)

[personal profile] deborah 2015-12-30 01:23 am (UTC)(link)
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:

adrian_turtle: stubborn little quilted turtle (Default)

[personal profile] adrian_turtle 2015-12-30 04:02 am (UTC)(link)
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."