A few hours ago I read about the aria-label attribute, which:
Defines a string value that labels the current element.
But in my opinion this is what the title attribute was supposed to do. I looked further in the Mozilla Developer Network to get some examples and explanations, but the only thing I found was
<button aria-label="Close" onclick="myDialog.close()">X</button>
Which does not provide me with any label (so I assume I misunderstood the idea). I tried it here in jsfiddle.
So my question is: why do I need aria-label and how should I use it?
It's an attribute designed to help assistive technology (e.g. screen readers) attach a label to an otherwise anonymous HTML element.
So there's the <label> element:
<label for="fmUserName">Your name</label>
<input id="fmUserName">
The <label> explicitly tells the user to type their name into the input box where id="fmUserName".
aria-label does much the same thing, but it's for those cases where it isn't practical or desirable to have a label on screen. Take the MDN example:
<button aria-label="Close" onclick="myDialog.close()">X</button>`
Most people would be able to infer visually that this button will close the dialog. A blind person using assistive technology might just hear "X" read aloud, which doesn't mean much without the visual clues. aria-label explicitly tells them what the button will do.
In the example you give, you're perfectly right, you have to set the title attribute.
If the aria-label is one tool used by assistive technologies (like screen readers), it is not natively supported on browsers and has no effect on them. It won't be of any help to most of the people targetted by the WCAG (except screen reader users), for instance a person with intellectal disabilities.
The "X" is not sufficient enough to give information to the action led by the button (think about someone with no computer knowledge). It might mean "close", "delete", "cancel", "reduce", a strange cross, a doodle, nothing.
Despite the fact that the W3C seems to promote the aria-label rather that the title attribute here: http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140916/ARIA14 in a similar example, you can see that the technology support does not include standard browsers : http://www.w3.org/WAI/WCAG20/Techniques/ua-notes/aria#ARIA14
In fact aria-label, in this exact situation might be used to give more context to an action:
For instance, blind people do not perceive popups like those of us with good vision, it's like a change of context. "Back to the page" will be a more convenient alternative for a screen reader, when "Close" is more significant for someone with no screen reader.
<button
aria-label="Back to the page"
title="Close" onclick="myDialog.close()">X</button>
If you wants to know how aria-label helps you practically .. then follow the steps ... you will get it by your own ..
Create a html page having below code
<!DOCTYPE html>
<html lang="en">
<head>
<title></title>
</head>
<body>
<button title="Close"> X </button>
<br />
<br />
<br />
<br />
<button aria-label="Back to the page" title="Close" > X </button>
</body>
</html>
Now, you need a virtual screen reader emulator which will run on browser to observe the difference. So, chrome browser users can install chromevox extension and mozilla users can go with fangs screen reader addin
Once done with installation, put headphones in your ears, open the html page and make focus on both button(by pressing tab) one-by-one .. and you can hear .. focusing on first x button .. will tell you only x button .. but in case of second x button .. you will hear back to the page button only..
i hope you got it well now!!
Prerequisite:
Aria is used to improve the user experience of visually impaired users. Visually impaired users navigate though application using screen reader software like JAWS, NVDA,.. While navigating through the application, screen reader software announces content to users. Aria can be used to add content in the code which helps screen reader users understand role, state, label and purpose of the control
Aria does not change anything visually. (Aria is scared of designers too).
aria-label
aria-label attribute is used to communicate the label to screen reader users. Usually search input field does not have visual label (thanks to designers). aria-label can be used to communicate the label of control to screen reader users
How To Use:
<input type="edit" aria-label="search" placeholder="search">
There is no visual change in application. But screen readers can understand the purpose of control
aria-labelledby
Both aria-label and aria-labelledby is used to communicate the label. But aria-labelledby can be used to reference any label already present in the page whereas aria-label is used to communicate the label which i not displayed visually
Approach 1:
<span id="sd">Search</span>
<input type="text" aria-labelledby="sd">
Approach 2:
aria-labelledby can also be used to combine two labels for screen reader users
<span id="de">Billing Address</span>
<span id="sd">First Name</span>
<input type="text" aria-labelledby="de sd">
The title attribute displays a tooltip when the mouse is hovering the element. While this is a great addition, it doesn't help people who cannot use the mouse (due to mobility disabilities) or people who can't see this tooltip (e.g.: people with visual disabilities or people who use a screen reader).
As such, the mindful approach here would be to serve all users. I would add both title and aria-label attributes (serving different types of users and different types of usage of the web).
Here's a good article that explains aria-label in depth
As a side answer it's worth to note that:
ARIA is commonly used to improve the accessibility for screen readers. (not only but mostly atm.)
Using ARIA does not necessarily make things better! Easily ARIA can lead to significantly worse accessibility if not implemented and tested properly. Don't use ARIA just to have some "cool things in the code" which you don't fully understand. Sadly too often ARIA implementations introduce more issues than solutions in terms of accessibility. This is rather common since sighted users and developers are less likely to put extra effort in extensive testing with screen readers while on the other hand ARIA specs and validators are currently far from perfect and even confusing in some cases. On top of that each browser and screen reader implement the ARIA support non-uniformly causing the major inconsistencies in the behavior. Often it's better idea to avoid ARIA completely when it's not clear exactly what it does, how it behaves and it won't be tested intensively with all screen readers and browsers (or at least the most common combinations). Disclaimer: My intention is not to disgrace ARIA but rather its bad ARIA implementations. In fact it's not so uncommon that HTML5 don't offer any other alternatives where implementing ARIA would bring significant benefits for the accessibility e.g. aria-hidden or aria-expanded. But only if implemented and tested properly!
I believe you should not use it at all unless you know what you are doing and you are going to check how it looks all over aria's supported devices. Don't bring a problem with the excuse of being a solution! 🙃 people with disabilities will thank you
Related
I currently have a simple bit of markup on my site, and can't seem to get a screen reader to read it. Am I missing something?
<section aria-label="This is the text I want to be read "></section>
I've also tried:
<section aria-description="This is the text I want to be read "></section>
The section isn't tabbable as such as its not a link, not sure if that's connected to the problem, but my understanding of whether the screen reader should or should not be reading something is sketchy at best.
Screen reader in question, if it matters.
https://chrome.google.com/webstore/detail/screen-reader/kgejglhpjiefppelpmljglcjbhoiplfn
Any help appreciated.
It might depend how you are navigating with the screen reader. Since the <section> is not a keyboard focusable element, I'm assuming you have some text content in it? Most screen readers will let you navigate to all elements on the page, including plain text, using the down arrow. The down arrow essentially walks the DOM. (It actually walks the accessibility tree but for now think of it as walking the DOM.)
If you can navigate to a focusable element before the <section> using the tab key, then you can start using the down arrow to get to the section.
With NVDA, I heard "This is the text I want to be read, region". Note that it's saying "region" because a <section> element has a default role of "region".
With JAWS, it did not read the aria-label, but that's because of the JAWS default verbosity settings which does not include regions. If you change your verbosity setting from the default "medium" to "high", then you will hear the section label when you arrow down to it. (Or you can configure your current verbosity setting to include regions.)
With JAWS, you can also navigate by landmarks. Since a <section> has a "region" role, and a region is a landmark, I can navigate by landmarks with JAWS using the R key and when I do that, I hear "This is the text I want to be read region", regardless of my verbosity setting.
So, as someone else posted, if you use a "standard" screen reader, the label will be read. If you use a lesser known screen reader, then it's hard to say what will happen.
Regarding aria-description, that's not production yet. It's part of the ARIA 1.3 specs which is still in draft form. The production ARIA 1.2 does not have aria-description so it's doubtful it will be read.
ACcording to ARIA specification, the <section> can perfectly have the aria-label attribute.
Most other HTML5 structural elements also allow aria-label because they are landmark regions.
So, conforming screen readers are supposed to read it, and, as far as I have tested, they indeed do.
Attribute aria-description is more recent than aria-label, so you should prefer aria-label in order to maximize the chances to have it read.
IN order to make good and relevant tests, I suggest you to use a true screen reader really used by users, rather than a browser extension that nobody use in the real life.
You may try one or more of the following, depending on your target systems and possibilities: (Non exhaustive list)
NVDA, Jaws and Supernova under windows
VoiceOver under MacOS, iOS and iPadOS
Talkback and VoiceAssistant under Android
NVDA, VoiceOver and Talkback are totally free, and VoiceOver is even always available out of the box without the need to install anything. So you really have no reason to don't try them out.
In striving for WCAG 2.0 Compliance, I'm finding quite a bit of varied information regarding proper treatment of buttons, specifically what is required to consider the button accessible and compliant.
What is the appropriate way to mark-up a <button>? What attributes or combination do they need to have?
My buttons fall into three categories:
Buttons that have text that describes their intended action. (e.g. "Learn More" to launch a modal with more product information)
Buttons that have text that does not describe their action. (e.g. "X" or text that titles a section of accordion content)
Buttons that do not have text that describes their intended action or otherwise. (e.g. An icon / image that switches the context of a carousel)
For instance, in the following simple example of 3 above: http://codepen.io/ga-joe/pen/ggeLeW
Is it acceptable to add only an aria-label attribute for a button with no text? Are name and / or value always required? Please send help! Thank you!
These seem to be the relevant WCAG Guidelines:
https://www.w3.org/TR/WCAG20/#text-equiv-all
https://www.w3.org/TR/WCAG20/#navigation-mechanisms-refs
https://www.w3.org/TR/WCAG20/#ensure-compat-rsv
These kinds of questions always depend on context. Let me give it a shot sans context.
<button>Learn More</button> does the trick as long as contextually someone will understand what they will learn more about. Usually the button is preceded by some descriptive text. However, if it just brings someone to another page as opposed to firing a modal, I would use a link.
<button aria-label="Close">×</button> for a close button (I am using the character entity for ×, which is more symmetrical than x. Again, if the button is at the top of a modal (for example), perhaps adjacent to its heading, then that is probably adequate.
<button aria-label="Image 1">[icon]</button> can work for a carousel. Note that a font icon can be lost if the typeface does not download. A background image will disappear in Windows High Contrast Mode (WHCM) for IE11 and older versions of Edge. The aria-label will not help the WHCM users. Probably best to use an image (even an SVG) and its alt attribute instead, which means then you do not need aria-label.
You do not need a name attribute. It does nothing useful here.
Do not use a role="button" attribute. That role is automagically part of the <button> element. If you assign another role, then you have a big problem.
Definitely do not use a title attribute. That does more harm than good.
Buttons that have text that describes their intended action. (e.g. "Learn More" to launch a modal with more product information)
You can read the recommendations for WCAG 2.4.9 Link Purpose (Link Only) even if we're not talking about links. The text "Learn more" can be understood when in context, but for low vision users who require screen magnifier, for instance, it can be difficult to understand the action from the button text itself.
For instance the text Learn more about "Wheels on the bus" may seem more appropriate.
Buttons that have text that does not describe their action. (e.g. "X" or text that titles a section of accordion content)
I answered that subject in another post:
What is aria-label and how should I use it?
You have to use both aria-label (useful for screenreaders) and title attributes (for standard users using standard browsers which may need more support):
<button
aria-label="Back to the page"
title="Close" onclick="myDialog.close()">X</button>
Buttons that do not have text that describes their intended action or otherwise. (e.g. An icon / image that switches the context of a carousel)
The same reasoning can apply to this point. But for blind people, moving a carousel to the left or to the right is a different experience, sometimes useless. If they can ignore that what they see is a carousel, without losing any content, navigating with the keyboard or their assistive technology, then you are doing what is expected.
Also, you have to never forget that accessibility does not only target blind users, but also children, old people, people with cognitive or sensitive disabilities. For instance, the aria-label will never be sufficient enough to help those people when needed. They do not have a screen reader, and they do not read the HTML source code.
In the case of users using "speech-recognition software" (yep, they are not a lot but let's improve their life), not having any visible text can also lead to difficulties.
I saw the documentation for ARIA 'role' but couldn't understand it. What exactly does it do? Say, I use it in a table like this:
<td role='button'>text</td>
does it mean that this cell will act like a button? Can someone explain this in simpler terms?
You can refer the MDN which says:
The button role should be used for clickable elements that trigger a
response when activated by the user. On its own, role="button" can
make any element (e.g. <p>, <span> or <div>) appears as a button
control to a screen reader. Additionally, this role can be used in
combination with the aria-pressed attribute in order to create toggle
buttons.
Also see the note
Where possible, it is recommended to use native HTML buttons
(<button>, <input type="button" /> and <input type="image" />) rather
than the button role, as native HTML buttons are more widely supported
by older user agents and assistive technology. Native HTML buttons
also support keyboard and focus requirements by default, without need
for additional customization.
The w3.org also has a detailed explanation of aria-role
As stated, ARIA is for accessibility and the role attribute won't have an effect on normal browsers.
One of the most simple and functional ways to implement ARIA roles is the use of Landmarks. Some ARIA roles are Landmarks, which allow users to jump to specific parts of the page in screen readers. Some blind users find this helpful as it helps them navigate quickly. Support and behaviour in different screen readers is described here.
I've a case where I'd like to use aria-label to give screen-readers access to the (CSS pseudo-)content. Something like this:
[data-pseudo-content]::before {
content: attr(data-pseudo-content);
}
<h1 aria-label="This is the title" data-pseudo-content="This is the title"></h1>
Is it bad to use aria-label for content rather than a label for the content? Also, would some screen-readers read This is the title twice?
To the best of my understanding, aria-label can be applied in some situations to change or enrich the accessible name of an element (= the textual representation that will be outputted to the user, either by speech or by braille).
The amount of influence of aria-label or aria-labelledBy on the accessible name depends on how much information the node contains and its type or role itself.
Your example (confirmed with NVDA on Windows 8.1 in Chrome 42 and Firefox 36) doesn't make much of a difference for a screen reader, as it will follow a set of rules to determine the accessible name. In my experience, a screen reader will - among others - give priority to the containing text if other conditions (role) fail. If the node would happen to be empty and other alternatives are not available, a screen reader will render aria-labelledBy or aria-describedBy as the accessible name if provided. Otherwise it will be ignored.
Luckily in your case, the ARIA standard also covers :before and :after as part as the algorithm for determining the accessible name. You can read more about how the accessible name is being computed at the spec: http://www.w3.org/TR/wai-aria/roles#textalternativecomputation
When would aria-label or aria-labelledBy make a good use? I'm still researching the subject, so I cannot provide a 100% certain answer for the time being. I do, however know that it makes a difference on elements like <input>. You should apply aria-label when there is no visible label available. It might also be useful to know that, whenever aria-labelledBy is rendered, it will always be placed first in the accessible name. This could be useful for form fields, because <label> might not always be rendered first if many attributes are given. aria-label / aria-labelledBy are also useful when you use the contenteditable attribute on an element, to make sure that the content is accessible for screen readers.
Here is a wiki with some examples of how aria-label / aria-labelledBy could be applied (search on page for those words): http://www.w3.org/WAI/GL/wiki/Category:ARIA_Techniques
Remember: the best way to figure out what works and what doesn't, is by playing around with a screenreader. I have not been able to test with other screen readers (apart from NVDA and iOs VoiceOver for a while), so the implementation on other screen readers like JAWS might differ. Other known screen readers are Windows Eyes and Supernova (though I heard that SN is not good with replacing focus with .focus(), so be careful). It might also be a good idea to test in different browsers, as the accessibility API might differ and give slightly different outputs.
The following HTML is inserted by the jQuery Grid plugin:
<td role="gridcell" style="" aria-describedby="list_createdBy">Sam</td>
What is the meaning of the 'aria-describedby' property?
This is described in the aria specification. It gives the id of an element that provides some additional information about the current element that some users might need.
Here below is an example of how you could use the aria-describedby property. It is used when you have a text that has information about the element. Aria-describedby must be the same as the id of the text that describes it.
First name: <input aria-describedby="name" type="text">
<em id="name">Your first name must be correct.</em>
At the first glance I'd say aria-describedby is likely to be ignored here because it's defined on <td>. Most browsers and screen readers will ignore aria-describedby information when set on element which is not interactive (focusable).
But the specific example a bit more complex due to role="gridcell" which overrides the semantics of <td> and therefore the provided example is valid if it follows the ARIA specification for gridcell. It's a custom component.
Generally speaking the attribute aria-describedby provides the screen reader with the additional information to be announced along the content of the element (not the only but the most common use-case).
For example instead of only "Logout" the screen reader will announce "Logout, John Doe":
Logged-in as <span id="user">John Doe</span>.
<a aria-describedby="user" href="/logout">Logout</a>
Or example with a tooltip (Hint: Javascript part is missing here):
<button type="button" aria-describedby="my-tooltip">Snipping Tool</button>
<div hidden id="my-tooltip" role="tooltip">
It can take still screenshots of an open window,
rectangular areas, a free-form area,
or the entire screen.
</div>
Or example with a form element, another common use-case:
<form ...>
<label for="my-name">Full name</label>
<input aria-describedby="my-name-desc" id="my-name" type="text"/>
<p id="my-name-desc">
Please tell us your full name.
</p>
</form>
The example above will announce both <label> and the additional description (defined by aria-describedby) immediately when a user focuses the input field. Not only that it eliminates a need to read the surroundings to be able to understand what is expected to enter but also reading all elements other than form controls when inside of the <form> might be more complex for a screen reader user. It's a different experience then reading the rest of the page. Because keyboard events can either interact with screen readers or with form controls, but hardly with both in the same time. Not to mention that screen readers offer bunch of useful keyboard shortcuts for example pressing "H" will jump to a next heading but obviously not when <input> field is focused. Then "H" will be entered into <input>.
About ARIA:
ARIA is commonly used to improve the accessibility for screen readers (not only but mostly atm.).
Using ARIA does not necessarily make things better! Easily ARIA can lead to significantly worse accessibility if not implemented and tested properly. Don't use ARIA just to have some "cool things in the code" which you don't fully understand. Sadly too often ARIA implementations introduce more issues than solutions in terms of accessibility. This is rather common since sighted users and developers are less likely to put extra effort in extensive testing with screen readers while on the other hand ARIA specs and validators are currently far from perfect and even confusing in some cases. On top of that each browser and screen reader implement the ARIA support non-uniformly causing the major inconsistencies in the behavior. Often it's better idea to avoid ARIA completely when it's not clear exactly what it does, how it behaves and it won't be tested intensively with all screen readers and browsers (or at least the most common combinations). Disclaimer: My intention is not to disgrace ARIA but rather its bad ARIA implementations. In fact it's not so uncommon that HTML5 don't offer any other alternatives where implementing ARIA would bring significant benefits for the accessibility e.g. aria-hidden or aria-expanded. But only if implemented and tested properly!
About aria-describedby
Provides the additional information along the content of the element
Works as expected on focusable elements (e.g. button, input, a). Mostly useless on other elements ("mostly" there are exceptions)
IE 11 is a bit tricky. Sometimes it's ignored. It might make a difference if implemented on a or button as well if referenced element is hidden (display:none), its position (is the inner element referenced?) or if it has tabindex="-1" or role (e.g. role="none") on it etc. Make sure to test all screen readers
Might behave differently if a screen reader is used in a focus mode (TAB key) or virtual mode (reading the content with ARROW keys)
Both Firefox and Internet Explorer respect aria-describedby only in focus mode. As such, it does not make sense to add it to non-focusable elements. From: ADG
While NVDA announces descriptions right away, JAWS sometimes prompts to manually press JAWS+Alt+R to announce it. From: ADG
If referenced element is hidden it's not searchable with Ctrl+F (which is a common way the users like to navigate the website to quickly find what they look for). From: ADG
The only case where we truly recommend the usage of aria-describedby, is to attach additional information to interactive elements (e.g. to relate visible information e.g. to form controls). From: ADG
Good idea: Using combination of aria-describedby (on a form control) and role="alert" (on a SPAN) for a form control error. From: W3.org
Basically,
aria-describedby property is used to attach descriptive information to one or more HTML tags through the use of an id reference list( an id reference list contains one or more unique HTML tag ids).
aria-describedby property is very similar to aria-labelledby property( a label which describes the essence of a HTML tag) but aria-describedby property provides more information about a HTML tag that user might need.
The properties aria-describedby and aria-labelledby are mainly useful to the users who use assistive technologies like a screen reader.
For reference:
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-describedby_attribute
https://www.w3.org/TR/WCAG20-TECHS/ARIA1.html