Have an Accessible New Year with these 12 Resolutions
I am writing this article as I return to California from a family holiday get-together, thinking about how to get rid of the 5 pounds I gained from my Cordon Bleu-trained mother-in-law’s cooking. That made me think about New Year’s. It’s right around the corner, and there is no better time than right now to undertake some New Year’s accessibility resolutions (in addition to getting rid of that 5 pounds if you feel like that is a thing you need to do).
January — Caption ALL your Videos
There is literally no better accessibility investment one can make than captioning videos. You must caption videos on your website and mobile app if you come under the ADA, but you should caption all of your companies’ videos, including all social media and internal training. Captioning videos:
Improves your SEO rankings
Improves video “stickiness” (people watch longer)
Makes the videos accessible to people who don’t have or can’t use headphones in places where playing videos out loud would be annoying or inappropriate (yes, I’m thinking of the person in 23D watching that pro-Trump video on a flight earlier this year)
And oh yeah
Solves the major problem of the largest group of people with disabilities — those with hearing loss.
It’s cheap. It’s easy. On behalf of mothers of d/Deaf children everywhere who are freaking tired of explaining to their beloved little ones why a particular company doesn’t give a
February — Get a head-start on WCAG 2.2 Level AA
It is never too early to start considering implementing WCAG 2.2. WCAG 2.0 was released in 2006, when mobile was still in its infancy. The majority of WCAG 2.1 pertains to native applications. Operating in both portrait and landscape mode, if it isn’t already implemented in your app, will probably be the most time-consuming to implement.
WCAG 2.2 largely focuses on cognitive accessibility improvements, extensions to previous focus management guidelines, dragging operations, and touch target sizes.
If you do one to two WCAG 2.1 and 2.2 Level AA guidelines a month in 2025, you're done! If you chose not to, you may have to explain in a deposition what was more important than providing fundamental civil rights under the ADA.
March — Start planning a disability focus group
You can’t possibly know how usable your product is to a new user with a disability unless you have done a usability study. This generally involves one or more focus groups or user interviews entirely concerning the issues facing users with disabilities. This process will undoubtedly give you a new perspective on what inexperienced users who rely on assistive technology think about how hard or easy your product is to use and what improvements they would like to see. I also had at least one “aha” moment per day during interviews where a user told me something that instantly made sense, but I hadn’t previously thought of the idea because I was too close to the product.
April — Think about older individuals
We are all aging, and just about everyone on this planet knows an older individual who has trouble reading small print. Five times as many people use magnification to see as there are screen reader users. After five eye surgeries and nine years with glaucoma, I am now one of them.
When you embed meaningful text in pictures, it becomes very hard to read when zoomed in. That is because the text is no longer text but dots in a picture. On the other hand, live text (i.e., text independent of the picture) magnifies well. This is even more important as most e-commerce transactions are now initiated on mobile devices with inherent space restrictions.
Color contrast is also critical to people with vision loss. Any time you use pastels, white on yellow, color on color (like tan on brown), or grey on white, you instantly lose people who can’t see low contrast, including most people over the age of 60.
May — Think about Dyslexia
WCAG includes only one guideline for people with dyslexia, which concerns the user’s ability to customize character, word, and line spacing. Yet people with dyslexia are rarely screen reader users and represent 5–7 % of the population, far more than any other individual disability. You can improve the experience of people with dyslexia by:
· Reducing the use of italics
· Eliminate the use of heavily scripted fonts
· Using only san-serif fonts
June — Get Rid of ALLCAPS
Study after study has shown that ALLCAPS are harder to read. Comprehension is lower, and it takes longer to understand the text. And it’s not the “I’m on your site shopping for more stuff” good definition of “longer”. It’s the “grr, I can’t understand this endless stream of characters” irritated definition of “longer”.
If that’s not enough to convince you, bugs and the use of lesser-known screen readers can cause ALLCAPS to be interpreted as abbreviations, which means it announces letter by letter. ADD ME becomes “a dee dee em ee.” It's not a great experience and definitely slows things down.
July — Review and Standardize Header Structure
Organizations need a comprehensive header framework standardized across all digital properties they support. Few have one. Given there is only H1 to H6 allowed, there are numerous ways headers can get messed up, including:
· Not using them for navigation
· Including too much punctuation or emojis
· Including non-standard abbreviations
· Skipping levels
August — Give the mouse a day off
When I say “give it a day off,” I mean disconnecting it and putting it in a drawer or disabling your trackpad. Then, you won’t be tempted to cheat.
To be accessible, you must be able to tab to every interactive component. You also must be able to navigate all lists, combo boxes, and menus using a keyboard. Fine, you say, we’ve tested that manually and are good to go. But is it usable? There are many keyboard-only behaviors that are nominally WCAG 2.2 Level AA compliant but not even remotely usable, including:
· Forcing people to hit the down arrow 29 times to enter a date in a required field that is later in the month
· Predictive search not announcing correct items as the suggestion list is traversed
· In-line field validation announcing every error remaining each time a user enters a character to set a new password
· Infinite scrolling (don’t get me started on this heinous UI practice)
· Back to top buttons that can’t be reached
September — Investigate supporting accessible chat
Accessible chat is the greatest thing since closed captioning, according to my millennial deaf daughter. It allows her to have a synchronous conversation with customer support without picking up the phone and calling someone, which she despises doing. Again, it is cheap, easy, and a curb cut because lots of people who don’t have a disability will appreciate it as well. I will likely be using Olark because my site won’t have millions of visitors per month, but there are plenty of turnkey accessible chat solutions available from vendors such as Nuance and Apple.
October — Accessibility Analytics
What do you know about your visitors with disabilities? Are they different in representation than the general population? If you want to implement a feature (not a WCAG guideline) and you only have enough budget to benefit one of the four types of disabilities, do you know which one disability category will get you the biggest bang for your buck?
You may know that 74 % of your customers are female, 19 % are between the age of 45 and 54 and your highest purchasing zip code per transaction is 92211, but if you don’t know that it takes screen reader users 3.3 times as long to put an item in a cart as a user without a disability (and whether 330 % longer is good or bad) you will not be able to take effective steps in improving your visitors’ with disabilities experience.
November — Look into Haptics
On mobile devices, haptics, in addition to sound, icons, and messaging, are great methods of communicating status on a native app. But for some people, haptics can be like nails on a chalkboard. Think about how you would implement them (short short long for an error, perhaps, and a single medium vibration for success) and then figure out how to do it in a way that makes everyone happy.
December — Reduce using non-modal dialogs
When I participate in a focus group or user interview (see March’s resolution) with a screen reader user on a website that includes non-modal dialogs, there is typically at least one instance where the non-modal has caused no end of confusion.
Modal dialogs keep the focus within the dialog. You can’t get to page content behind the modal, and you can’t return to that content until you have completed the modal action (typically OK/Cancel, occasionally combined with another operation). Some UI designers see this as a friction point for users without disabilities, thus preferring not to use them.
Non-modals do not retain focus. When you reach the last element and hit the tab key or swipe, it goes back to the page content, usually, but not always, to the component that launched the non-modal dialog. This makes it extremely difficult for screen reader users to figure out where they are, how to get back to the dialog, and most importantly, how to proceed with whatever transaction they came to your site to execute. If you haven’t added elements to your non-modal to tell the screen reader user what to do, they may shop elsewhere.
Conclusion
Even WCAG-compliant companies with strong accessibility programs need an annual accessibility plan. Companies can always improve on user experience. The experience of users with disabilities is no exception to this rule. Eventually, WCAG compliance will no longer be a competitive differentiator because everyone in the US who comes under 508 or the ADA will be following it. What will be a competitive differentiator are site/app behaviors that improve the experience of people with disabilities that don’t come under WCAG. Get ahead of your competitors and start looking at the experiences of users with disabilities holistically, not just through the WCAG compliance lens.