I am writing this article as I am returning 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. Which 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).
I will attempt to do the first article of every month in 2019 as a deep-dive on how to accomplish the suggested accessibility resolution for that month.
January — Caption ALL your Videos
There is literally no better accessibility investment you 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:
1) Improves your SEO rankings
2) Improves video “stickiness” (people watch longer)
3) Makes the videos accessible to people who don’t have or can’t use headphones in places that 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
4) 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 deaf children everywhere who are freaking tired of explaining to their beloved little ones why a particular company doesn’t give a <bleep> about them (my personal favorite was “Mom, why doesn’t Amazon care that I’m deaf?”), just do it.
February — Get a head-start on WCAG 2.1 Level AA
It is never too early to start looking into implementing WCAG 2.1. The majority of WCAG 2.1 pertains to native applications, which really weren’t much of a “thing” when 2.0 was released in 2006. The two items that could take the most time to implement are:
1.3.4 Making sure that native apps operate in both portrait and landscape mode
2.5.4 One stop motion deactivation
If you do one WCAG 2.1 Level AA guideline a month for the rest of the year after these two in February, you’re done !
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, which generally involves one or more focus groups or user interviews entirely concerning the issues facing users with disabilities. This process will certainly give you 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 have at least one “aha” moment per day of 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. There are three times as many people who use magnification to see as there are screen reader users. After 5 eye surgeries and 9 years with glaucoma, I am now one of them.
When you embed meaningful text in pictures, it becomes very hard to read when zoomed. That is because the text is no longer text, it is dots in a picture. Live text (i.e. text that is independent from the picture) magnifies well independently. As most e-commerce transactions are now initiated on mobile devices with inherent space restrictions, this is even more important.
May — Think about Dyslexia
WCAG does not include any guidelines for people with dyslexia. 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 less, and time required to understand is longer. 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 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” Not a great experience, and definitely slows things down.
July — Header Structure
Few companies have a comprehensive header structure that is standardized across all digital properties they support. 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
· Including non-standard abbreviations
· Skipping levels
August — Give the mouse a day off
And when I say “give it a day off” I mean disconnecting it and putting it in a drawer, or disabling your track pad. Then you aren’t tempted to cheat.
To be accessible, you must be able to tab to every interactive component. You also must be able to navigate a list using a keyboard. Fine, you say, we’ve tested that manually and we are good to go. But is it usable? There are many keyboard-only behaviors that are nominally WCAG 2.1 Level AA compliant, but not even remotely usable including:
· Forcing people to hit the down arrow 29 times to get to 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 as a user is typing a 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 having to pick up the phone and call someone, which she despises doing. Again, 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
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 the use of unenhanced non-modal dialogs
When I have participated in a focus group or user interview (see March’s resolution) with a screen reader user on a property 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 get to the last element and hit the tab key or swipe, it goes back to the page content, usually but not always where the non-modal was launched from. 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 companies who are WCAG compliant and have strong accessibility programs need an annual accessibility plan. Companies can always improve on user experience, and the experience of users with disabilities is no exception. 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 users’ with disabilities experience holistically and not just through the WCAG lens.
0 comments on “Have an Accessible New Year with these 12 Resolutions”