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();
Related
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.
I have read on Mozilla website regarding the title attribute : "contains a text representing advisory information related to the element it belongs to".
But also, in the first paragraph of the page regarding all global attributes (title included): "HTML defines a few attributes that are common to all HTML elements. These attributes can be used on all elements, though the attributes may have no effect on some elements"
Is it anywhere specified (source please) on which element the title attribute has "no effect"?
I curious why this seems so vague, maybe I simply missed something.
I created a jsfiddle where title attribute seems to "have an effect" (on Chrome, FF29, IE11) on tags: <a>, <img>, <p>, <div>
It depends on HTML version where the title attribute is valid. Originally, it was allowed for links (a elements) only and was meant to help the user see, on mouseover, some information about the linked resource, useful for deciding whether to follow the link or not. This might still be regarded as the most useful way of using title.
Later, the attribute was allowed for most elements, and HTML5 proposes to remove all restrictions, mainly just for simplicity. The formulation about the effects is intentionally vague, since the effects are expected to be browser-dependent, and they often are. For example, speech-based browsers may optionally speak the title attribute value when encountering an element that has it; but this can usually be switched off.
For example, in HTML5, the title attribute is also allowed for a head element, but it normally has no effect there, since that has no content to be rendered (as part of the document).
The title attribute is mostly used to show users information (“tooltip”) on mouseover. This is in many ways problematic, due to the primitive and uncontrollable user interface and other problems. Therefore, people often use other techniques, such as “CSS tooltips”, instead. But for compatibility with past specifications and practices, title attributes are kept as part of the language. It is unlikely that its meaning will be specified more exactly.
What I am seeing on the Internet a lot is that the ARIA roles on HTML5 tags are mostly an exact duplicate (in meaning) of the tag name itself. Why would you want to do that? I'd say you could deduct certain roles just by looking at the tag name.
For example on this "ARIA Role Cheat Sheet website" I see the following:
<nav role="navigation></nav>
<main role="main"></main>
<aside role="complimentory"></aside>
Also in Twitter Bootstrap in the examples a form has the role form: e.g <form role="form">
I'd say, no kidding? When it has something like a search role <form role="search"> it actually provides context what cannot be deducted from the tag itself.
Is it correct to leave the roles empty in the earlier mentioned cases? Where it does not give any apparent extra information about the tag.
The ARIA (Accessible Rich Internet Applications) attributes are meant to be used for elements that are used to create a user interface in a manner that cannot be deduced from the markup otherwise. The reason is that this may help user agents and assistive software to help the user with such elements. Think about a span element that acts as a submit button, or as a checkbox, or as text input widget.
So we are not expected to use ARIA attributes for elements used in their simple, natural meanings. Thus, it is in principle redundant to declare role=navigation for a nav element, since that element has this role as the default and as the only permitted role (as per current specs and drafts). But as #Alohci points out, the attribute may still help, if a user agent is advanced enough to recognize the attribute but not new enough to know the element.
The document Using WAI-ARIA in HTML (Working Draft, 3 October 2013) presents some recommendations on explicitly specifying ARIA attributes, based on information about user agents. Such information is of course mutable, but we can expect that any attibute specified as redundant there will remain redundant. In particular, it says that for nav, main, and aside a role attribute should be specified, but not for form (because user agents surely know the form element).
In contrast, the W3C HTML5 draft, which was recently moved back to LC status, says: “In the majority of cases setting an ARIA role and/or aria-* attribute that matches the default implicit ARIA semantics is unnecessary and not recommended as these properties are already set by the browser.” It specifically says that the role attribute should not be set for nav, main, or aside when its value would match the default value.
WAI-ARIA is older than HTML5. Screen readers implemented support for ARIA roles before HTML5 was mainstream, so for some users the ARIA roles provide benefit even when the equivalent HTML5 elements do not.
Although screen readers are catching up, remember that upgrading a screen reader (unlike upgrading a browser) is an expensive process, so old screen readers are in use far longer than old browsers.
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
One of our web applications just went through 508 compliance testing. We use TinyMCE version 3 for content development and I understand it generally has good accessibility. However, one of our pages contains 3 or more TinyMCE instances each preceded by a label indicating what the TinyMCE instance is for but we are being told that these are "implicit" labels when they should be "explicit" labels (i.e. with the for attribute). Problem is, TinyMCE instances are just iframes with a complex assortment of custom html "controls", whereas as far as I know the label/for technique only works with traditional form elements. What's the best strategy for achieving an "explicit" label for a TinyMCE instance?
Thanks!
Edit
Solutions explored using label + for which don't work: pointing the label at the initial textarea, pointing the label at the generated iframe.
One possible solution I am exploring is encompassing each TinyMCE instance with a ledgend + fieldset but testing this out with JAWS 9.0 it doesn't seem to make any difference unless the fieldset contains form elements (e.g. input, type=text) and JAWS is in forms mode.
There is an emerging standard for exactly this kind of problem: ARIA (Accessible Rich Internet Applications). It's still a working draft, but support is beginning to show up in recent screen readers (JAWS 9, recent versions of NVDA) when used with recent browsers (IE 9, Firefox 3.6 (partial) and 4.0, Chrome).
In this particular case, take a look at aria-label and aria-labelledby. These are attributes which would be added to the BODY element in TinyMCE's widget -- or to the IFRAME, whichever of the two actually takes focus when the user is entering data. Thus:
<body aria-label="Edit document">
The aria-label attribute just specifies a string that serves as the label. The aria-labelledby (note the two L's, as per British spelling) works like the traditional LABEL element in reverse. That is, you feed it an ID:
<body aria-labelledby="edit-label">
And then you would have this someplace else in the code:
<label id="edit-label">Edit document</label>
It doesn't necessarily have to be a LABEL element, you could use a SPAN or whatever, but LABEL seems semantically appropriate.
ARIA attributes will not validate under HTML 4, or XHTML DTD's. However, they WILL validate under HTML 5 (itself still in development). If validation is important to you under an older DTD, you can add the attributes programmatically using JavaScript when the page has loaded.
Ideally, if you have a visible label for the widget already, then you should be using aria-labelledby to prevent redundancy. However, I have no idea if it'll work across document boundaries. That is, if the BODY is in an IFRAME, and the visible label is defined in the IFRAME's parent document, I don't know if it'll work. The browser/screen reader may treat the two as separate documents which don't talk to one another. You'll have to experiment to find out. But if it turns out they don't work, try http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden. Thus, in the parent document:
<label aria-hidden="true">Edit document</label>
And in the TinyMCE document:
<body aria-label="Edit document">
The aria-hidden attribute will prevent the label in the parent document from being read, and the aria-label attribute in the child document (which is not visible) will take its place. Voila, a widget labeled both visibly and audibly with no redundant reading.
If you use aria-hidden this way, be very careful that the bit you're hiding (or an equivalent) is always made available for reading someplace else.
This solution will only work for people using web browsers and screen readers that support ARIA. People with older screen readers or browsers will be out of luck, which is discussed at length in the recent article on A List Apart, The Accessibility of WAI ARIA. The author makes a good case for preferring traditional semantic HTML solutions whenever possible; but in your case I don't think you have any other option. At the very least, adding ARIA attributes will let you reasonably claim that you've done your due diligence and made a good faith effort to make it as accessible as possible.
Good luck!
Note to far future readers: The links to the ARIA specification given here refer to the September 2010 working draft. If it's been more than a few months since then, check for more recent specs.
Using the information Will Martin provided regarding the aria-label attribut, I wrote the following line of code which works for TinyCME 4:
tinymce.init({
…
init_instance_callback: function(editor) {
jQuery(editor.getBody()).attr('aria-label', jQuery('label[for="' + editor.id + '"]').text())
}
});
It uses the callback function triggered after initialisation of the editor.
There has to be a label targeted at the original element on which TinyMCE is call upon, in my case a textarea. e.g.:
<label for="id_of_textarea">Shiny wysiwyg editor"</label><textarea id="id_of_textarea"></textarea>
The content of the label (text only) is added as aria-label attribute to the body tag inside the TinyMCE-iframe.
OSX screenreader is propperly returing the label when selecting the TinyMCE
Some inspiration from TinyMCE: How bind on event after its initialized
If I read the specs right, the for property must indeed point to another control on the same page, as you already say.
Therefore, I think the only valid option is to point the for attribute to the <textarea> element that TinyMCE replaces. It makes the most sense, seeing as that element gets sent to the server when editing is finished.