Not so short note on aria-label usage – Big Table Edition – HTML Accessibility
This is a very handy table of elements from Steve of where aria-label
can be applied.
Like, for example, not on a div
element.
This is a very handy table of elements from Steve of where aria-label
can be applied.
Like, for example, not on a div
element.
Another five pieces of sweet, sweet low-hanging fruit:
- Always label your inputs.
- Highlight input element on focus.
- Break long forms into smaller sections.
- Provide error messages.
- Avoid horizontal layout forms unless necessary.
Five pieces of low-hanging fruit:
- Unlabelled links and buttons
- No image descriptions
- Poor use of headings
- Inaccessible web forms
- Auto-playing audio and video
A handy reminder from Léonie (though remember that the best solution is to avoid the problem in the first place—if you avoid using ARIA, do that).
A great explanation of aria-label
and aria-labelledby
!
A deep dive with good advice on using—and labelling—sectioning content in HTML: nav
, aside
, section
, and article
.
Some good advice from Hidde, based on his recent talk Six ways to make your site more accessible.
When in doubt, label your icons.
When not in doubt, you probably should be.
A good look at the (over)use of the aria-label
attribute that confirms the first rule of ARIA.
Something that I am increasingly uncomfortable with is our industry’s obsession with job titles. I understand that the landscape has gotten a lot more complex than when I started out in 2009, but I do think the sheer volume and variation in titles isn’t overly helpful in communicating what people actually do.
I share Andy’s concern. I kinda wish that the title for this open job role at Clearleft could’ve just said “Person”.
A lot of the issues here are with abuses of the placeholder
attribute—using it as a label, using it for additional information, etc.—whereas using it quite literally as a placeholder can be thought of as an enhancement (I almost always preface mine with “e.g.”).
Still, there’s no getting around that terrible colour contrast issue: if the contrast were greater, it would look too much like an actual pre-filled value, and that’s potentially worse.
The answers to these questions about forms are useful for just about any website:
- Is It OK To Place A Form In Two Columns?
- Where Should Labels Be Placed?
- Can We Use Placeholder Text Instead Of A Label?
- How To Lessen The Cognitive Load Of A Form?
- Are Buttons Considered Part Of A Form’s UX?
- Is It Possible To Ease The Process Of Filling A Form?
- Does The User’s Location Influence A Form’s UX?
Adam Silver is writing a book on forms—you may be familiar with his previous book on maintainable CSS. In a recent article (that for some reason isn’t on his blog), he looks at markup patterns for search forms and advocates that we should always use a label. I agree. But for some reason, we keep getting handed designs that show unlabelled search forms. And no, a placeholder is not a label.
I had a discussion with Mark about this the other day. The form he was marking up didn’t have a label, but it did have a button with some text that would work as a label:
<input type="search" placeholder="…">
<button type="submit">
Search
</button>
He was wondering if there was a way of using the button’s text as the label. I think there is. Using aria-labelledby
like this, the button’s text should be read out before the input field:
<input aria-labelledby="searchtext" type="search" placeholder="…">
<button type="submit" id="searchtext">
Search
</button>
Notice that I say “think” and “should.” It’s one thing to figure out a theoretical solution, but only testing will show whether it actually works.
The W3C’s WAI tutorial on labelling content gives an example that uses aria-label
instead:
<input type="text" name="search" aria-label="Search">
<button type="submit">Search</button>
It seems a bit of a shame to me that the label text is duplicated in the button
and in the aria-label
attribute (and being squirrelled away in an attribute, it runs the risk of metacrap rot). But they know what they’re talking about so there may well be very good reasons to prefer duplicating the value with aria-label
rather than pointing to the value with aria-labelledby
.
I thought it would be interesting to see how other sites are approaching this pattern—unlabelled search forms are all too common. All the markup examples here have been simplified a bit, removing class
attributes and the like…
The BBC’s search form does actually have a label:
<label for="orb-search-q">
Search the BBC
</label>
<input id="orb-search-q" placeholder="Search" type="text">
<button>Search the BBC</button>
But that label is then hidden using CSS:
position: absolute;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px, 1px, 1px, 1px);
That CSS—as pioneered by Snook—ensures that the label is visually hidden but remains accessible to assistive technology. Using something like display: none
would hide the label for everyone.
Medium wraps the input
(and icon) in a label
and then gives the label
a title
attribute. Like aria-label
, a title
attribute should be read out by screen readers, but it has the added advantage of also being visible as a tooltip on hover:
<label title="Search Medium">
<span class="svgIcon"><svg></svg></span>
<input type="search">
</label>
This is also what Google does on what must be the most visited search form on the web. But the W3C’s WAI tutorial warns against using the title
attribute like this:
This approach is generally less reliable and not recommended because some screen readers and assistive technologies do not interpret the
title
attribute as a replacement for the label element, possibly because thetitle
attribute is often used to provide non-essential information.
Twitter follows the BBC’s pattern of having a label but visually hiding it. They also have some descriptive text for the icon, and that text gets visually hidden too:
<label class="visuallyhidden" for="search-query">Search query</label>
<input id="search-query" placeholder="Search Twitter" type="text">
<span class="search-icon>
<button type="submit" class="Icon" tabindex="-1">
<span class="visuallyhidden">Search Twitter</span>
</button>
</span>
Here’s their CSS for hiding those bits of text—it’s very similar to the BBC’s:
.visuallyhidden {
border: 0;
clip: rect(0 0 0 0);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
width: 1px;
}
That’s exactly the CSS recommended in the W3C’s WAI tutorial.
Flickr have gone with the aria-label
pattern as recommended in that W3C WAI tutorial:
<input placeholder="Photos, people, or groups" aria-label="Search" type="text">
<input type="submit" value="Search">
Interestingly, neither Twitter or Flickr are using type="search"
on the input
elements. I’m guessing this is probably because of frustrations with trying to undo the default styles that some browsers apply to input type="search"
fields. Seems a shame though.
Instagram also doesn’t use type="search"
and makes no attempt to expose any kind of accessible label:
<input type="text" placeholder="Search">
<span class="coreSpriteSearchIcon"></span>
Same with Tumblr:
<input tabindex="1" type="text" name="q" id="search_query" placeholder="Search Tumblr" autocomplete="off" required="required">
…although the search form itself does have role="search"
applied to it. Perhaps that helps to mitigate the lack of a clear label?
After that whistle-stop tour of a few of the web’s unlabelled search forms, it looks like the options are:
label
element,aria-label
attribute,title
attribute, oraria-labelledby
.But that last one needs some testing.
Update: Emil did some testing. Looks like all screen-reader/browser combinations will read the associated text.
A clever technique by Emil to implement the “float label” pattern using CSS. It all hinges on browsers supporting the :placeholder-shown
pseudo-class which, alas, is not universal.
I was hoping that maybe @supports
could come to the rescue (so that a better fallback could be crafted), but that tests for properties and values, not selectors. Damn!
A great run-down by Heydon of just one ARIA property: aria-label.
A look at the risks of relying on a purely graphical icon for interface actions. When in doubt, label it.
I really like this interface idea from Brad that provides the utility of input masks but without the accessibility problems.
This looks like a nifty take on the ol’ using-labels-like-placeholders pattern for forms. I still prefer to have a label visible at all times, but this seems like a nice compromise.
An examination into the legibility of labels on online mapping services.
Excellent! Warning labels for bad journalism for you to print off and stick on.