If something is native HTML, it has to be good, right? After all, it wouldn't be there if it wasn't....and HTML should be used over ARIA at all times when possible, right?
Well, no. There are a few native HTML attributes that are terrible for accessibility, and which I wish would just die. I have to mention them when doing accessibility audits, because they simply don't work very well for disabled people, in various ways. Without further fanfare, here are the culprits in my list. There might be others, but these are the ones that immediately come to mind.
The title attribute
The title attribute. Want to provide some extra information for users, but don't want it visible onscreen? I know, let's slap a title on it!
No. Don't. Please don't.
The title attribute is terrible for accessibility, and is not exposed to the majority of users. Users who don't see or hear titles:
- Users browsing on mobile phones or other touchscreens
- Users with motion disabilities navigating by keyboard or keyboard-alternate devices
- Many blind users—screen readers have uneven support for titles. VoiceOver on Mac, for instance, doesn't read titles, just informs users that the item has a "help tag" and they have to press a special key combination to hear it.
So who does see titles? Sighted users who happen to mouse over the element and hold their mouse still long enough for the title to appear. But, it has other issues:
- The font it displays in is extremely small. It does not resize when browser zoom or font size are increased. Low-vision users are out of luck.
- It displays as a popup tooltip, so it may overlay and obscure other content.
Some screen reader users will hear titles. But when they do, I find IRL that the title attribute often repeats text already present in the element's visible label. And, when the element has an aria-label and a title, the title is never read (at least in NVDA); or, when it's an image and has alt text, the title is not read (also in NVDA).
Tl;dr: don't use the title attribute on anything except iframes and RSS feed links. For iframes, the title is required to provide the iframe's accessible name. For RSS feed links, it's the title of the link in RSS readers, apparently.
If you need to provide extra information for users, 99% of the time that information should just be present in the link's visible text, the input's visible label (if there isn't one, that's another problem), or what have you. Don't make information hard for users to find.
Placeholders in form inputs
This is one of the most common accessibility issues I see. Minimalism! Clean design! Let's put our form input "labels" inside the input, so we don't have things like useful information users need cluttering up our beautiful design!
So what's the problem with that? Placeholders disappear as soon as the user types anything into the input. Then, if they can't remember what the purpose of the input is and what the heck they're supposed to be typing into it, they have to clear out what they've already typed to get their cue back again. This is particularly a problem for users with cognitive disabilities or memory impairment, or blind users.
Placeholders also often have insufficient contrast, making them potentially unreadable for users with low vision. And if they have sufficient contrast, they risk being confused with actual input, potentially making users think there's already data in the field and not filling it out.
The same goes when using placeholders for input format hints, rather than as labels.
Just use actual <label> labels. Don't forget to use the for attribute to programmatically associate them with the input.
For help text, put it outside the input and use aria-describedby to programmatically associate it with the input.
The disabled attribute
This is another one I see frequently: disabled buttons or form inputs, with absolutely no explanation of why they are disabled.
The problem with the HTML disabled attribute is that it makes elements unfocusable by the keyboard. So blind users tabbing through a form, for instance, won't find a disabled submit button and may conclude that there isn't one at all.
The solution? Well, I recommend not disabling form elements or controls at all. It's a terrible user experience, mainly because it doesn't tell users why the element is disabled, or what they have to do to enable it.
What to do instead? Clearly mark form fields as required (no details here, there's plenty of information out there on how to do that accessibly). Provide good, clear help text. When users submit forms with errors, provide clear, plentiful, accessible error handling and messaging.
If you absolutely feel you must disable something, don't do it. If you're still determined, use aria-disabled="true" instead. Note that aria-disabled won't prevent form submission; you have to code that in.
Secondly, provide an accessible description of why the control is disabled and what the user has to do to enable it. E.g. "Fill out all required fields to submit this form" adjacent to an aria-disabled form submit button. Use aria-describedby to programmatically associate this text with the submit button. Remove the text when the button becomes enabled.
But just don't disable things.
The required attribute
This is less of an issue than the prior ones, but it's a bit annoying. You might think that using required on a form input would be a good thing. But it results in screen readers announcing an error for the input when it is focused, before the user has attempted entering data in the field or submitting the form. NVDA, for example, says "Invalid entry". This is annoying for blind users, as well as somewhat misleading as they haven't attempted to enter anything in the field yet, much less submit the form.
What to do instead:
- Recommended: put "required" wording in the input label, e.g. "Email address (required)." This covers both sighted and blind users, and no further action is needed. It's also far more understandable than an asterisk for sighted users.
- Or, put
aria-required="true"on required inputs. (Don't forget a visible required marker for sighted users, and if you use an asterisk, you have to add an explanatory note at the beginning of the form). This results in inputs being announced as "required", but no error announcements. - Don't use both "required" wording in labels and aria-required on inputs. This results in screen readers announcing "required" twice for each input, which, while it's much better than no required marker, is annoying.
So that's my roundup of bad-guy attributes which, while they are native HTML, are accessibility crap and should be avoided. There might be others, if you think of one I welcome comments!