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.
Related
I am creating a search form that has two elements an input field and a button. The input field does not have an label associated with it.
To make the field more accessible I can add <label for="searchfield">Search</label> and visually hide it so it will e.g. be accessible for screenreaders.
I could also add aria-label="search" to the input field and leave the input field without an label.
I have tested with "Voice Over" on a Mac and I get the same result/output. My question is are these approaches equivalent? Or is one approach better than the other one?
Here is a pen.
In the absence of having any knowledge of the site (how are other form fields labeled?) or the audience (what is their skill level or tech profile?), I approach these questions with a couple parameters:
The rules of ARIA (the first rule may apply here)
Progressive enhancement
That being said, I often code a page without ARIA and without CSS (as that may get blocked, chunked, etc) and make sure it is accessible.
That means I code a <label>. Then I visually hide it. If the CSS breaks, all is still well. If the user's screen reader does not support ARIA, all is still well. As an aside, if you think all screen readers of your users support ARIA, I encourage you to do to a tech assessment of users (local blind associations are a good start in the absence of any real users). Many people still run older versions of browsers and SRs.
For sighted users, I make sure I lean on contextual clues, like a clear search icon (or the word) in the button (as Unor references). Or maybe a placeholder with appropriate contrast (though you could use the <label> as a visual placeholder with some CSS trickery to hide it on focus).
If your submit button uses SVG, then I would be folding ARIA into that given the inconsistent support around SVG alternative text methods.
FWIW, I am also not a fan of the title attribute, partly because of inconsistent accessible name calculation and partly because I think it looks meh.
So, to answer your questions:
My question is are these approaches equivalent?
No, but the distance between them is shrinking.
Or is one approach better than the other one?
That depends on context we do not have.
Using aria-label is preferable to relying on CSS to visually hide a label element.
(Related Technique: Using aria-label to provide an invisible label where a visible label cannot be used)
But note that you don’t have to provide a label for a search form that only consists of the search field and the submit button. Assuming that you use a button labeled with something like "Search", it already makes clear which purpose the text field has.
(Related Technique: Using an adjacent button to label the purpose of a field)
In that case, while it doesn’t need a label, it should still get a name. One way to provide a name is to use the title attribute on the input element. The Technique Using the title attribute to identify form controls when the label element cannot be used shows this (a search form without label, with title attribute on input) in example 3.
I believe that aria-label="search" is the correct approach, as it produces cleaner markup (i.e. no unnecessary label tag) and no need for CSS to set visibility of the label - like in this example.
I believe visually hiding a label using CSS is a somewhat 'hacky' way to approach the problem, whereas ARIA is the standard for accessible markup, so it should be the obvious choice for situations like this.
On the other hand, it would be worth ensuring all browsers you intend to support can use ARIA correctly, and if not, it may be worth using the label approach to ensure compatibility across all browsers. Although, I think the support these days is pretty good, so that should not be a common scenario.
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();
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
I've seen many uses of rich-text or at least natural-looking text editing being made available with seemingly any of a page's text-containing elements. What are my options to have this for myself?
I think you may be referring to the contenteditable attribute in HTML5. This attribute allows any arbitrary HTML element to literally become editable. It has a fairly wide support, mainly because before its appearance in the HTML5 specs it is actually a proprietary Internet Explorer attribute.
The downside of this is that, like any other form element, the appearance and capabilities of this varies wildly from browser to browser, and the quality of the HTML produced is truly atrocious. Still, if you want to have a look, go ahead and hit some of these links:
http://html5demos.com/contenteditable
http://blog.whatwg.org/the-road-to-html-5-contenteditable
Are you looking some some thing like tinymce ? If so check this