The first group of patterns we will review for accessibility are ubiquitous to almost every website or app: buttons. [...]<button type="button" aria-describedby="button-example">Sign up</button><span id="button-example" class="visually-hidden">for our monthly newsletter</span>
[...] While this pattern is slightly more complex, it adds a lot in terms of context by creating a relationship between the button and the purpose. When in doubt, anytime we can add more context to the situation, the better, so we can assume if coded correctly, it is the best pattern when comparing only these specific button patterns.
The second group of patterns we will review are contextual links. [...]<p>"People waste their time pondering whether a glass is half empty or halffull. Me, I just drink whatever's in the glass." — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>
[...] According to the ARIA specs from the W3C "The purpose of
aria-labelis the same as that of
aria-labelledby. It provides the user with a recognizable name of the object." So, in theory, both attributes should have the same basic functionality.
However, the specs also point out that user agents give precedence to
aria-labelwhen deciding which accessible name to convey to the user. Research has also shown issues around automatic translation and
aria-labelattributes. So that means we should use
Well, not so fast. The same ARIA specs go on to say "If the interface is such that it is not possible to have a visible label on the screen (or if a visible label is not the desired user experience), authors should use
aria-labeland should not use
aria-labelledby." Talk about confusing — so which pattern should we choose?
If we had large-scale translation needs, we might decide to change the visual aspect and write out the links with the full context displayed (e.g. "Read more about this awesome thing") or decide to use
aria-labelledby. However, let's assume we did not have large-scale translation needs or could address those needs in a reasonable/accessible way, and we didn't want to change the visual — what then?
Based on the current ARIA 1.1 recommendations (with the promise of translation of
aria-labelin ARIA 1.2) plus the fact that
aria-labelis a bit easier for devs to implement versus
aria-labelledby, we could decide to weight
aria-labelledbyin our pattern evaluation. This is a clear example of when context weighs heavily in our accessible pattern choice.
- <button type=".." class="..">Add <span class="visually-hidden">PRODUCT_NAME</span> to Cart</button><!-- P.S. Don't do this -->
You include the product name in the button's text label string, so then when the Form Controls menu displays the list of buttons, each button would be clearly labelled to indicate which bottle it is referring to.
This is a good solution for a screen reader user navigating using Form Controls, but you do not want to do this because even though it improves the experience of some screen reader users, it excludes users of other assistive technologies and makes these buttons inaccessible to them, and a pain to use…
[...] When the dragon user (in the video) wants to select a form control, he speaks out the visual text label of that control. This is one of many reasons why visual labels are important in user interfaces.
So when we have a series of Add to Cart buttons, a dragon user will speak the label of the button in order to interact with it. This is why adding text in the middle of the string makes it inaccessible. The content in the middle of the string would break the visible label. The user would be telling dragon to interact with a button whose label is not what it visually appears to be. This is why this would fail the WCAG Success Criterion 2.5.3: Label in Name: "For user interface components with labels that include text or images of text, the name contains the text that is presented visually. A best practice is to have the text of the label at the start of the name."
[...] It turns out, there is a middle ground here. We can still add the product name to the button, improving the user experience for screen reader users, without breaking the visible name of the button, by appending it to the end of the button's name, instead of inserting it in the middle.<button type=".." class="..">Add to Cart <span class="visually-hidden">, PRODUCT_NAME</span></button>
By appending the text to the end of the visible name, the visible name is left intact, and the Web Rotor Form Controls menu will show a list of Add to cart buttons with the names of the products they are referring to appended to them.
As for the voice control user, when they say "click Add to Cart", Dragon is going to label the Add to Cart buttons with numbers, [..] and then the user can speak out the number of the button they want to click. This works because Voice commands work by saying the name of the input you want to interact with, as long as the name is not "broken" or interrupted by content in the markup.
So whenever you need to add additional text to a visible label, it best come after what's visually shown.
Often, developers go too far treating images as decorative. When JAWS or VoiceOver find no images, or only a few with meaningful alt text, I know I'm probably missing out on something. Sometimes I can guess the context of an image.
[...] I find that The Atlantic has been leveling-up its alt text skills. I've found a mix of short and long descriptions, both of which have been helpful in understanding the image and its purpose. An example I recently found on the homepage is "a grasshopper waits on a vaccine syringe," next to a headline about second vaccine doses. Though some may deem this a decorative image deserving of an empty alt, I disagree. I appreciate getting this much information by just browsing a homepage. It feels like I'm getting the same information a sighted reader would get after skimming the headlines and their corresponding photographs.