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.
Related
For the HTML title attribute, Mozilla's docs mention...
Use of the title attribute is highly problematic for:
People using touch-only devices
People navigating with keyboards
People navigating with assistive technology such as screen readers or magnifiers
People experiencing fine motor control impairment
People with cognitive concerns
This gives me a seed of doubt whether I can innocuously use title all over the place.
Would the mere existence of title actually introduce problems for certain users?
Or put another way, is there any benefit using title other than for showing-supplementary-information-as-rudimentary-tooltips-for-mouse-users-that-hover-an-element?
I'm just trying to maximize my UX & accessibility optimizations to 110%.
I can conceive of three different problems that using title attributes can introduce for those various groups.
No access
Some users don't use technology that would display the title attribute. This isn't a problem is the title attribute contains information that isn't required to understand the content.
Physically getting in the way
A tooltip might cover up some other information when it is rendered. You can probably compensate for this with space. Don't cram everything together. Allow enough room on a hover target so a tooltip can render in empty space, or at least space that doesn't contain information about the element being hovered.
Interruptions
If you scatter titles in the middle of a sentence, then I expect some screen readers will interrupt the sentence to read the tooltip. This won't make it easy to understand the document if it happens a lot.
I wouldn't go overboard with them.
(Related, but less of an accessibility issue, if the titles duplicate information in the text, then it is going to be very repetitive and annoying).
That depends, as always. Usage of the title attribute is not harmful, but relying on it is.
To quote the HTML standard:
Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g., requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).
https://html.spec.whatwg.org/multipage/dom.html#the-title-attribute
Mostly, title is used to implement the tooltip pattern, which is then not very accessible, as stated.
So if you provide that supplemental information by accessible means as well, the title attribute does most likely not harm.
“[…] is there any benefit using title other than for showing-supplementary-information-as-rudimentary-tooltips-for-mouse-users-that-hover-an-element?”
Well, the WCAG accept title attributes as a sufficient technique to explain abbreviations in an <abbr> element or to label form controls, even though actual technical support is not great.
To name <iframe> elements it is still the only documented sufficient technique
If you use it on <style> and <link> elements, it allows the browser to provide a style switcher.
<link rel="stylesheet" href="dark.css" title="Dark Theme">
See also The Trials and Tribulations of the Title Attribute
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.
I am looking to break up a word for display purposes, but would like to maintain accessibility if a screen reader were to access the word. Is this possible?
<span>T</span><span>itle</span>
<span>T</span><span>i</span><span>t</span><span>l</span><span>e</span>
I would like the two examples to read "Title" as that is essentially how they would display. The entities do not need to be spans and the block can be wrapped in another element if that is required.
What would be the best way of achieving this behaviour while allowing the letters to be styled individually, without the use of javascript?
You can also use the aria-label attribute on a wrapping span to ensure it is read the way you want it to be heard:
<span aria-label="Title"><span>T</span><span>itle</span></span>
This is also a useful technique for symbols and other content you want to ensure is read properly, but you should double-check on an actual reader to make sure it is actually spoken as intended.
I made a demo of your example: http://s.codepen.io/aardrian/debug/wodLOz
Both NVDA and JAWS read each one as "title." What that tells me is that you are unlikely to have to do anything as they are read fine.
A div is neither landmark nor interactive content. An aria-label will not be read by a screen reader (and rightly so). So that approach would not not work anyway. If you were stuck, I would look at accessible off-screen options anyway.
Just fire up more screen readers and give it a go (VoiceOver, TalkBack, Orca, Narrator are good ones to use).
The problem here seems to reside in your screenreader or the way you use it.
Using Chromevox, I can see this "bug" when I navigate directly (using shortcut CHROMEVOX+arrow) to the element, but not when I launch the whole page read (using shortcut CHROMEVOX+R).
The problem is due to the granularity used to read the document. Unfortunately the current version of Chromevox is so buggish that I can't find any solution to change that granularity using the defined shortcut (CHROMEVOX+-).
Note that as long as you use non-block-level elements, a good screen reader should announce this correctly, which is not the case of Chromevox, for instance which handles differently those elements:
<b>T</b>itle <-- This is read separately (but should not)
and
<span>T</span>itle <-- This is (correctly) read as a whole word
Chromevox is a very peculiar screen reader because it's the only one who does not use the native browser accessibility API. Others screen reader won't even know that the text is contained inside a span.
I have been seeing the aria attribute all over while working with Angular Material. Can someone explain to me, what the aria prefix means? but most importantly what I'm trying to understand is the difference between aria-hidden and hidden attribute.
ARIA (Accessible Rich Internet Applications) defines a way to make Web content and Web applications more accessible to people with disabilities.
The hidden attribute is new in HTML5 and tells browsers not to display the element. The aria-hidden property tells screen-readers if they should ignore the element. Have a look at the w3 docs for more details:
https://www.w3.org/WAI/PF/aria/states_and_properties#aria-hidden
Using these standards can make it easier for disabled people to use the web.
A hidden attribute is a boolean attribute (True/False). When this attribute is used on an element, it removes all relevance to that element. When a user views the html page, elements with the hidden attribute should not be visible.
Example:
<p hidden>You can't see this</p>
Aria-hidden attributes indicate that the element and ALL of its descendants are still visible in the browser, but will be invisible to accessibility tools, such as screen readers.
Example:
<p aria-hidden="true">You can't see this</p>
Take a look at this. It should answer all your questions.
Note: ARIA stands for Accessible Rich Internet Applications
Sources: Paciello Group
Semantic Difference
According to HTML 5.2:
When specified on an element, [the hidden attribute] indicates that the element is not yet, or is no longer, directly relevant to the page’s current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user.
Examples include a tab list where some panels are not exposed, or a log-in screen that goes away after a user logs in. I like to call these things “temporally relevant” i.e. they are relevant based on timing.
On the other hand, ARIA 1.1 says:
[The aria-hidden state] indicates whether an element is exposed to the accessibility API.
In other words, elements with aria-hidden="true" are removed from the accessibility tree, which most assistive technology honors, and elements with aria-hidden="false" will definitely be exposed to the tree. Elements without the aria-hidden attribute are in the "undefined (default)" state, which means user agents should expose it to the tree based on its rendering. E.g. a user agent may decide to remove it if its text color matches its background color.
Now let’s compare semantics. It’s appropriate to use hidden, but not aria-hidden, for an element that is not yet “temporally relevant”, but that might become relevant in the future (in which case you would use dynamic scripts to remove the hidden attribute). Conversely, it’s appropriate to use aria-hidden, but not hidden, on an element that is always relevant, but with which you don’t want to clutter the accessibility API; such elements might include “visual flair”, like icons and/or imagery that are not essential for the user to consume.
Effective Difference
The semantics have predictable effects in browsers/user agents. The reason I make a distinction is that user agent behavior is recommended, but not required by the specifications.
The hidden attribute should hide an element from all presentations, including printers and screen readers (assuming these devices honor the HTML specs). If you want to remove an element from the accessibility tree as well as visual media, hidden would do the trick. However, do not use hidden just because you want this effect. Ask yourself if hidden is semantically correct first (see above). If hidden is not semantically correct, but you still want to visually hide the element, you can use other techniques such as CSS.
Elements with aria-hidden="true" are not exposed to the accessibility tree, so for example, screen readers won’t announce them. This technique should be used carefully, as it will provide different experiences to different users: accessible user agents won’t announce/render them, but they are still rendered on visual agents. This can be a good thing when done correctly, but it has the potential to be abused.
Syntactic Difference
Lastly, there is a difference in syntax between the two attributes.
hidden is a boolean attribute, meaning if the attribute is present it is true—regardless of whatever value it might have—and if the attribute is absent it is false. For the true case, the best practice is to either use no value at all (<div hidden>...</div>), or the empty string value (<div hidden="">...</div>). I would not recommend hidden="true" because someone reading/updating your code might infer that hidden="false" would have the opposite effect, which is simply incorrect.
aria-hidden, by contrast, is an enumerated attribute, allowing one of a finite list of values. If the aria-hidden attribute is present, its value must be either "true" or "false". If you want the "undefined (default)" state, remove the attribute altogether.
Further reading:
https://github.com/chharvey/chharvey.github.io/wiki/Hidden-Content
setting aria-hidden to false and toggling it on element.show() worked for me.
e.g
<span aria-hidden="true">aria text</span>
$(span).attr('aria-hidden', 'false');
$(span).show();
and when hiding back
$(span).attr('aria-hidden', 'true');
$(span).hide();
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