All Caps - an accessibility bug
The top left menu bar in gray above left, has All Caps issues. Why?...text-transform in style.
No need to push back on the Designers, but need to inform its a bug if left untreated.
Yes, go to the URL and test it yourselves at: www.unitedhealthgroup.com.
- Both UNITEDHEALTHCARE and OPTUM are read letter by letter;
- This is a bug issue on many sites;
Aria - An Accessibility Fix for All Caps
- Whether the text is All Caps or styled to transform to upper case, a simple aria label will save the day and prevent these usability issues;
- As shown top right, the fix is to place an aria label on the All Caps tag, such as: aria-label="Optum";
- How does this happen?
Its because Aria takes precedence: When an aria-label is used along with the native labelling techniques, the aria-label takes priority. Ergo, on an image, if both alt text and aria-label are used then aria-label information will be read for screen reader users. Similarly, on buttons, if both name value and an aria-label are provided, aria-label takes priority. And be aware that when aria-label and aria-labelledby are used, aria-labelledby will take priority with Screen Readers.
Both CSS and the Mis-use of ARIA create accessibility bugs
Like the use of All Caps with transform styling:
- Because many Dev teams think aria-labels automatically enhance User Cues, I am seeing hyper-links with both link text and aria-labels;
- With the semantic rule of Aria labels taking precedence, only the aria label gets read. And this is prevalent on many sites with links having link text and aria labels;
A reasonable question among accessibility SME's "So, is it possible for a web page to be overly accessible?" (asked by Jared Smith -WebAim)
- I think Caitlyn Mayers gives a perfect answer. Thank you Caitlyn. And thanks for the question Jared.
"No. I’d define overly accessible as inaccessible. You can make the experience worse by implementing accessibility features incorrectly, which is the antithesis of accessibility as a practice / design philosophy."(caitlynmayers's Tweets)
- Just because a web team is using all the right ingredients is not sufficient or helpful;
- Unless the HTML is implemented with proper semantics it can be a house of cards for the User Experience and accessibility;
- Case in point: Links and bad use of Aria with Screen Reader User : "Members while supplies last with their Club Card". Message is not understandable! And this mis-use of Aria is on many retail web sites;
<p>Members <a href="#" aria-label="while supplies last"> get 20% savings</a> with their Club Card. </p>
- Another case in point with many online retailers: <button class="actionButton " action="list-add" productkey="Safeway/of@545687dd-4bc8-41a9-be41-b348b6646387-2">Add to List</button>
The button uses text-transform and conveys: "A, D, D, to list" on all button items, not Add.
Conclusion
Good intentions benefits no one, only good semantic code. Therefore, web teams need to:
- Learn proper HTML semantics and apply it correctly;
- Use Aria for All Caps bug fixes; and
- Web applications are not done until tested by QA for accessibility.
Pete nicely said! Developers do sometimes over do Aria, especially when applying fixes. The focus should be to do it right the first time around. Taking the example of “all caps” - Brand style guide should clearly define the instances when all caps can be used. If we start applying a11y at this level we can avoid accessibility issues in later stages of design and development.
I agree that it is possible to over-do accessibility; however in most cases, providing too much accessibility markup does not make the page inaccessible. Rather, providing too much accessibility markup can start to interfere with usability. For instance, providing the title attribute, name attribute, and ARIA on the same button can cause screen readers to read too much (repetitive) information; this is annoying and sometimes confusing to the people who rely on output from screen readers. In my job, I try to help developers discover the happy medium between having too much or too little accessibility markup. This is where it gets tricky and why employing real users to test the accessibility of products is so important. Provide too little accessibility and many people are unable to use the product, but provide too much and people will not want to use the product. The trick is finding the balance.
Pete you wrote nice article , however the challenge is to provide the know how - therefore when you use virtual overlay that provide “first aid” and in parallel provide the know how and fully instructions for dev team or once the organization have the priority this is Make-Sense