I am working on creating accessible help text for my form controls. I am planning to use aria-describedby to attach a accessible description to a field. This approach is discussed here
Although in my testing with ChromeVox extension and Windows 10 screen reader I have found out that aria-describedby is not announced, but it is rather well supported across browsers and screenreaders, so i am planning to use this approach.
Also this suggests that in some cases aria-describedby would be ignored or not work as expected but these cases are quite specific and i am generally ok with it.
aria-describedby content may not always be announced to users,
depending on their screen reader and navigation method. The attribute
is well supported, but that doesn’t mean there aren’t some things to
be aware of: aria-describedby content may not be announced by all
screen readers if navigating to a button, link, or form control with
the virtual cursor. JAWS specifically may not announce an element’s
description when using hot keys to navigate to certain elements. When
navigating by visited links, the description will not be announced.
However JAWS should announce descriptions when navigating by form
controls. JAWS 17 + IE won’t announce aria-describedby content when
tabbing to a link (newer version of JAWS have fixed this). IE11 won’t
announce the accessible name or description of a form control if the
title attribute is used in tandem with aria-describedby, and the
user is navigating by virtual cursor or form control hot key (F). Both
will be announced if using the Tab key. (IE11 had much bigger problems
with aria-describedby in the past.) TalkBack + Android Chrome won’t
announce any aria-describedby content of a modal dialog when
auto-focusing an element within that dialog. If a user has
descriptions or hint text turned off, any associated content won’t be
announced. Because of this, it’s vital that any content that is
necessary to the understanding of a UI be available by means other
than just aria-describedby.
I would like to understand if there are times when aria-describedby would not be announced automatically? The previous link phrasing seems to suggest that it is only going to be announced on request :
By using aria-describedby to reference the format of the field, this
information is made available to the users on request. That is, it is
not automatically displayed or read aloud. This makes sense if the
user has been informed of the format before, or when there are lots of
input fields with the same format, for example.
I don't get what it means by "on request". I believe that the default behavior is to announce the aria-describedby text after announcing the label and the input type.
The behavior of aria-describedby (like aria-label and aria-labeledby) is profoundly influenced by the role of the element where they appear.
As you may know screenreaders generally have two 'modes', and this is mostly determined by the role (or default semantics) of the content.
I have certainly had problems getting non-interactive elements announced, if they appear within interactive ("forms mode") content.
I have had good results using aria-describedby with modal content. (Put the attribute on the modal, and point at the text elements inside which you want announced when the modal opens.) But I suppose this is because there is an obvious moment where the screenreader is supposed to make those announcements: the moment when the modal opens.
In the case that the form (or other "forms mode" container) is always present on the page, you can usually read the non-interactive content using browse-mode key combinations such as "next heading" ("H" on NVDA and JAWS) or "next paragraph" ("P"). Check to see if these 'requests' are enough of a solution.
You might also experiment with the standard HTML elements fieldset and legend, whose purpose is providing a text description for groups of interactive elements.
Also consider treating the 'form' (or toolbar or whatever) as a single tab stop, and use arrow keys to navigate the components within. This way, when you give focus to the container, you should get an announcement of whatever is aria-describedby (or indeed aria-labeledby/aria-label)
If this isn't working for you, there are a couple of hacks you might try as a last resort:
Put tabindex="-1" on the element surrounding the text you want
announced, and then call focus() on that element at the appropriate
moment.
Copy the text into the textContent of an aria-live region
with javaScript at the appropriate moment.
Neither of these hacks are pretty, and might not suit you, if there is no 'appropriate moment'. (There's no equivalent of onfocus for browse mode). But with a little care, they can be made to work.
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.
Please correct me if I am wrong, but usually screen reader navigation works by pressing the tab key, and usually you do not have (or need) tab-able images. Therefore, when is the alt text actually useful to the screen reader?
I have seen examples where the screen reader reads things when pointed/selected by mouse (mostly for testing), but I am not sure if that is a practical usage.
(Another scenario that comes to mind is link images where the alt text might be used for link description.)
Please help me with more info.
usually screenreader navigation works by pressing tab key
Typically only interactive items - links, buttons, and the like - are accessible by tabbing. But screenreader users need to be able to access all content on the page - not just the interactive items. Think of how useless a wikipedia page would be if you could only read out the links on it, and none of the content.
Screenreaders generally provide a set of tools and commands for navigating a web page:
The simplest approach is to move linearly through the page, item by item. This will cover everything: non-interactive items, interactive items, text, images, everything!
The user can also navigate between items of a similar type - from one list item to the next, or from one table to the next, or from one image to the next
There are generally also commands to navigate the heading structure (H1...H6).
Users can also search for specific text on the page, and then continue reading or exploring from there.
Check out this list of shortcuts for common screenreaders from accessibility specialists Deque.
Several screenreaders intercept and capture most keyboard input while the user is using them: if you're using JAWS or NVDA, for example, hitting the down arrow key causes the screenreader to move to the next item instead of causing the browser to scroll down. Likewise, hitting H causes the screenreader to move to the next heading - the browser never sees that keypress. (If you tab to an input field, however, the screenreaders will let the input go through.) On the Mac, the VoiceOver screenreader instead uses keyboard modifiers for its commands - or example, Control+Option+RightArrow moves to the next item.
Using a screenreader to navigate and read a page is perhaps a surprisingly interactive experience: you're not just listening to what the screenreader is reading out (or equivalent if using Braille), but using commands to tell it where to navigate next. A user might start off reading down through the initial part of the page to see what's there, then switch to heading navigation to see what the overall page structure is and find a specific section, then read through that item by item. If the user is familiar with a page, they might use the search command to find some well-known piece of text and jump straight there.
This isn't all that different than how sighted users might view a page: visually scanning the top level structure, reading the headings, and then reading a particular section. But whereas most sighted users take this process for granted, when using a screenreader, you have to do it manually.
Please correct me if i am wrong, but usually screenreader navigation works by pressing tab key, and usually you do not have (or need) tab-able images
Yes this is wrong.
WebAIM publish the list of shortcuts for NVDA or JAWS
The tab key is only used to "Navigate to Next form Control".
You have different shortcuts to read the text, and the alternative text will be spoken when reading an image.
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.
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.