Three Key Accessibility Lessons
This was my third year at CSUN, the premier conference on assistive technology. If you’re interested in accessibility, it’s the place to be. I presented (or was part of presenting) three sessions. (You can see more at my conference resource page.)
This year there wasn’t a single big theme that I took away (like I did when I was thinking about making elearning accessible in 2017 and using pattern libraries in 2018.) Instead, my takeaways were more impressionistic. Three of those impressions were:
- If someone says that they are 100% accessible, don’t believe them. This was something I heard in many sessions, in many ways. Accessibility is a journey. Technology is always changing and aligning technology and accessibility is an ongoing project. Work toward it, be humble, be honest, and do what you can
- Remove burdens related to navigation. Provide a way to skip to the content for learners using the keyboard. Make sure that information doesn’t repeat for those using screen readers. This is standard good practice. What impressed me this year was the forcefulness of the point: if people spend their time being frustrated by navigation, then they won’t focus on what they need to learn (a point relevant for those with disabilities and without).
- People want to create learning that’s accessible—it’s a goal that I heard again and again. It’s a challenge, though, while elearning development tools are getting better, there aren’t any that give elearning developers everything they need: advanced interactions, ease of use, and the ability to fully meet accessibility requirements. Ironically, the best method might be to return to creating elearning using HTML (or, more accurately, HTML5). Creating elearning in HTML5 can be challenging, but the results can be impressive, both in terms of effective learning and accessibility.
In short, accessible elearning, like accessibility in general, remains an ongoing work in progress.
This Month in Learning
Isak Skogstad interviews the opinionated and entertaining Paul A. Krischner on whether we should let learners discover what they need or provide direct instruction instead (spoiler: in Krischner’s opinion, it’s most definitely the latter).
Fabricio Teixeira gives us, via Fast Company, a comprehensive list of user experience cliches . Many of which apply to learning and development. Many of which I’ve used.
Ever use a button when designing elearning? I thought you might have. One (or more) of these five lessons from Rachel Plotnick’s seven years of research into buttons might be helpful.
I found this article on the rise of tasting expertise fascinating (being a sommelier for honey is now a thing). How do you define expertise? How to you certify expertise? How do you certify that anyone is an expert in anything?
Do you need to deliver training in multiple languages? Laura Godfrey’s post on designing for translation offers guidance that may be useful.
Ever been asked to estimate how long it will take you to develop training? Jessica Greene-Zapier at Fast Company provides a handy list of effective methods to estimate time .
Do you struggle with drawing the line between perfect elearning and good enough elearning? Jonas Downey at the Signal v. Noise blog offers insights on managing the boundary , based on his work with the project management app Basecamp.
Do people learn better from their peers? If so, why? Connie Malamed uses the question as a jumping off point to discuss the importance of understanding how we organize and store knowledge in long-term memory .
Last year’s Starbucks diversity training initiative received a lot of attention. Yet ongoing work calls into question the idea of “implicit bias.” At Quartz, Olivia Goldhill asks whether “implicit bias” is real, and whether training about implicit bias is effective.
And for a little bit of fun. How are you at identifying issues with visual design? Give “Can’t Unsee” a try and see how you do.