For my study project I'm currently checking an example website for WCAG 2.1 compliance.
Checking it with different tools I still get some Warnings I don't understand or know how to solve.
One of the warnings is "title on non interactive element": I have some title="" attributes on <div>, , and elements and get a Success Criterion 3.3.2 Labels or Instructions warning.
I know the title attribute is not always read by the screen reader. But if I don't expect it to, where's the problem? I even tried to add an aria-label="" with the same content as the title but still get a warning for the title attribute.
<div class="criterion_secion" id="criterion_214" title="Success Criterion '2.1.4 Character Key Shortcuts'" aria-label="Success Criterion '2.1.4 Character Key Shortcuts'">...</div>
I believe that the warning is given because it’s not expected to have a label or a title on a non-interactive element, like a div.
A div is by nature a non-interactive element. We could make it interactive through the tabindex attribute or by giving it a role. However, I would advice not to do that and just use the div for what it's intended, as a container.
It make sense your tool are flagging title on non interactive element as a warning, because a lot of users can't access to your content in the title attribute. A warning doesn't mean it's automatically a failure.
The aria-label attribute on a div (without role attribute) is useless. This element have no semantic and it's not supposed to have an accessible name.
ARIA & Tooltips: 2 commonly misunderstood attributes
There is a very easy solution to this issue: remove both title and aria-label attributes and include their content that reads "Success Criterion '2.1.4 Character Key Shortcuts'" inside the DIV element, if not already included.
aria-label
The aria-label attribute defines a string value that labels an interactive element.
First of all, ARIA is for the screen readers only and it overwrites the accessible name of the element.
For example,
<label for="name" aria-label="surname">Name</label>
<input id="name" type="text" />
will be announced as "surname" and the screen reader user will never understand it is for the input field that collects users' "name".
As for the non-interactive elements, a paragraph never needs any aria-label for the simple reason that you can always include whatever information you want inside it. Besides, it may not be read or may confuse your users as a non-interactive element that acts like an interactive one.
It is also important to know that repeating what is already available as text with an aria-label is simply a nuisance, making the screen reader say the same thing twice or even thrice sometimes, along with a tooltip.
Tooltips
Tooltips are intended for sighted users. They provide some extra information that was not made available elsewhere. Examples from Mozilla.
It is helpful to understand these:
Tooltips are not accessibility features
Repeating what is already available as text using the title attribute helps no one and annoys screen reader users. It is simply bad practice.
Here is a comprehensive resource that will probably make you think twice before using another tooltip: If you want to hide content from mobile and tablet users as well as assistive tech users and keyboard only users, use the title attribute.
Related
I am making a table using HTML. It needs to meet WCAG standards, but I am having issues understanding what is an acceptable caption for a table. Can I use <h1> and aria-describedby instead of a <caption> element?
I have followed a W3 Web Accessibility tutorial - all of their examples meet WCAG. Though it seems like my table doesn't meet WCAG H39 Using caption elements to associate data table captions with data tables.
Based on Approach 2 from W3 this is what I currently have:
<h1 id="tableHeading">Table of requests</h1>
<p>Some other text that is relevant to the page</p>
<table aria-describedby="tableHeading">
....
You first have to understand that elements can have an "accessible name" and an "accessible description". The "accessible name" is often just referred to as the "name" and is what assistive technologies use to refer to the element. For example, the name is what is announced by a screen reader when you navigate to the element and the name is what a speech interface user would say to select the element ("click <name>").
In your example, which refers to Approach 2 from W3, aria-describedby is setting the "accessible description" of the table. The <caption> is what sets the accessible name. Note that the W3 example sets both and not just aria-describedby.
So, if you only use aria-describedby and not also a <caption>, then you are only setting the description of the table. The table won't have a name for the screen reader to announce but it will still announce the description.
So the answer to your question is, "not exactly". You can use an <h1> and aria-describedby but it does not replace <caption> because the caption is the accessible name of the table. But you can tweak it a bit and use <h1> and aria-labelledby instead of a caption to set the accessible name.
Note that you can have a <caption> that is not visible so that the accessible name is set (and the screen reader announces it) in case you are worried about the aesthetics of the page and don't want a visible caption. Visible captions are a best practice but you can certainly hide it if needed. But don't hide the caption with CSS display:none. Instead, hide it with CSS that essentially sets the size to 1 pixel using something like an "sr-only" class.
I've tested your example in Chrome 94 using JAWS 2020 and NVDA 2021.2 and I can't see any problem with using an <h1> tag with aria-describedby on the <table> element instead of using <caption>. Both screen readers announce the <h1> with aria-describedby in exactly the same manner as the native <caption> element, and treat the <h1> text as the table's caption when the <caption> element is removed.
Many applications use custom table layouts where <caption> is not applicable, so they instead rely on aria-labelledby or aria-describedby to name the table and describe its contents.
In my opinion, the WCAG recommendation is there to ensure that developers use standard HTML5 elements as much as is practical, but your method of using <h1> and aria-describedby achieves the same effect. So, use standard HTML5 elements wherever possible; where it's not possible (i.e. you don't have control over that portion of the code) you can use ARIA to achieve the same effect for screen readers.
On my web page, I have a div (shown below), which has text in it that I want to be read by a screen reader.
HTML
<div tabIndex={0}>
"text needs to be read"
</div>
I can hear the text is read without even providing the aria-label. However, I heard "text needs to be read group". I would like to know how can I avoid it saying "group"? I did not put a group role for the div tag.
Another example
This is another example that describes the problem much cleaner
<span class="jw-icon jw-icon-inline jw-button-color jw-reset jw-text-live" tabindex="-1" data-clicked="true">Live</span>
Run the above snippet in any browser. It makes the screen readers to announce it as "Live, group".
Is there any way to mitigate this behaviour. Expected behaviour should be like the screen readers should read it as "Live"
Lots of things going on here.
First of all, all text on a webpage is available to a screen reader and does not need tabindex="0" to make it available to be read. Screen readers provide lots of shortcut keys to navigate to different types of elements (headings, tables, lists, etc). For elements that don't have a direct navigation key, the screen reader user can use the up/down arrow keys to walk the accessibility tree (similar to the DOM).
Secondly, regarding tabindex="0", it should only be set on interactive elements. The tabindex spec says:
authors should only make elements focusable if they act as interactive controls or widgets. In addition, authors should ensure that these focusable elements have an appropriate ARIA role attribute.
And regarding ARIA roles in the second sentence in the spec quote, if your element does receive focus, if it's not a natively focusable element (such as a <a> or <button> or <input>), then it needs to have an appropriate role so that the screen reader user will know how to interact with it.
And related to this, you mentioned aria-label. The aria-label is only honored on elements that have an appropriate role. See "2.10 Practical Support: aria-label, aria-labelledby and aria-describedby".
So given all that, it's a little difficult to answer your question because your simple example is not specific enough. A <div> without a role should not read as "group". Group is usually role="region" (or <section>). The behavior you're hearing may depend on what browser you're using, what screen reader, how you're navigating in with the screen reader (tab or arrow or quicknav key).
I'm currently trying to make a DOM element with one to several child elements as accessible as possible. The element will contain illustrative content using background images in several layers. I'm currently using a child element for providing the image description as described in this informative blog post about how to label illustrative content inside of a content group. The container element may also contain other child elements containing text content.
An example element would currently look as follows:
<div tabindex="0" class="comic-panel">
<span role="img" aria-label="There is a cat sitting in the window."></span>
<div style="background-image: url(/assets/img/window.png);" class="comic-panel__layer"></div>
<div style="background-image: url(/assets/img/cat.png);" class="comic-panel__layer"></div>
<p class="speech-bubble">Meow!</p>
</div>
Testing with OSX VoiceOver, after tabbing into this element, the image description and the text is read fine, but subsequently, the following announcement is made as well:
Is it possible to update the markup of this element in a way, that this group announcement is not made by screenreaders? In almost all cases there will be nothing for the user to further explore or use inside of the element so this message would be redundant and I'd like VoiceOver to not recognise the element as a group that triggers this message.
(Moving all my comments from the comment section to the answer section since the discussion in the comments resolved the issue.)
I think there might be some misunderstanding of how a screen reader (SR) works and how a SR user navigates a webpage.
You have tabindex="0" on your <div> but the <div> doesn't have a role and is not an interactive element. The tabindex spec has a warning that says:
"authors should only make elements focusable if they act as interactive controls".
So unless the user can actually interact with the <div>, it should not have tabindex="0".
If the user can interact with the <div>, then the <div> will also need a role (see previous URL to role) so that the SR will announce the element properly and the user will understand how to interact with that element.
For non-interactive elements, SR users have lots of ways to navigate around the page so that they can access other text on the page.
One of the more common ways to navigate is by using the up and down arrow keys to walk the DOM. (Actually, you're not walking the DOM, per se, but rather the Accessibility Tree, which is basically a subset of the DOM. For example, hidden elements (CSS display:none) are in the DOM but are not in the Accessibility Tree.)
Anyway, the up/down arrow keys let the SR user get to every piece of text on the display. All your headings, paragraphs, lists, etc.
There are also single letter shortcut keys that allows the SR user to navigate to specific types of elements. For example,
H will take me to the next heading
T will take me to the next table
L will take me to the next list
B will take me to the next button
But these keys will only work if you are using semantic html, such as an <h2>, <table>, <ul>, <button>, etc or if you are using the appropriate ARIA attributes. For example, if there's a reason you can't use <h2> to make a real heading, you can still tell the SR that you have a heading by using ARIA.
<span role="heading" aria-level="2">This is a custom h2 heading</span>
JAWS and NVDA are common SRs on the PC. They'll have similar single key shortcuts that can be seen here:
JAWS shortcut keys
NVDA shortcut keys
VoiceOver shortcut keys (for the Mac, not iOS). Note that these are not single key shortcuts, like a simple H, but require the "VO" key (Ctrl+Option by default) in combination with Cmd and H.
Apple has a good tutorial on VoiceOver.
For the PC, Freedom Scientific (the maker of JAWS) has a good tutorial on JAWS.
If you have questions about accessibility, posting on stackoverflow is certainly one way to go, especially if you tag your question with accessibility and other accessibility related tags (such as wai-aria or screen-readers, as you did on this question).
Another resources is the WebAIM community. Anyone can join and you can "lurk" and just read the discussions as they come in, or fully participate.
I'm adding various Accessibility standards to our enterprise platform UI framework. We use a web client, DOM elements, etc. We render all of the framework in the DOM, but widgets in the framework can (and have for years) been put together in non standard ways by customers to build out various pages of their UI.
I've managed to cover and handle much of the specifications (I think), but I have a specific case, where we have "texty labely widgets" that are used to describe various "input / formlike widgets". Their only connection as far as the DOM goes is a common parent "container" element, a variable distance up the tree.
The ARIA guidelines I'm coming across (which at any point I may have misunderstood) suggest I need to use aria-labeledby="id_of_text_label_widget" on the actual form element. Meaning what I have now is:
<div id="parent_label_value_widget_001">
<div class="inputLabel">This is visible Label Text</div>
<div class="various_other_junk_in_here"></div>
<div class="some_wrapper_around_the_input">
<input id="I_am_the_form_input_in_question_with_a_very_long_id" value="42">
</div>
</div>
I could easily add the aria-labeledby attr to the input, but it means I'd need to add an id to the inputLabel element. And while this seems like not a big deal (it's slightly more complicated because what you see in the DOM is the result of a far more complicated render cycle from a WYSIWYG editor of disconnected widgets), it happens to be, with no possibility for change, that our ids are incredibly long already. Due to huge pages, sometimes tens of thousands of fields and nested dynamic things, etc
Our Ids make up 60% of our payload. And I'd effectively have to double that chunk by adding a new id to every label element, and our content isn't gzipped. So that's what I'm trying to avoid. I actually also don't want to do it for other reasons, as the label widget and the input widget actually know nothing about one another, so I'd have to write some extra render logic to have the input widget pull the id from the sibling label widget.
My question is: does anybody have any other solutions?
Things I've imagined:
A. Is there some technique using aria-label, where I could label the parent container and have screen readers know how to link the internal label and input?
B. I could duplicate the label text from the label widget onto the input widget and use aria-label="duplicated text". I could do this server side with some pain, or client side with some clumsy walking logic, but would rather avoid the duplication, and the extra logic. But if I do that, then do I need to aria-hide all the existing label widgets?
C. Is there some shorthand for <label for=""> or aria-labeledby="" where instead of an id, it can reference elements by css selector, or proximity? (Dreaming, I know), but it's a shot.
D. Make the user opt in to aria support, and only then do they get the doubled package size. (yeah, I know gzip would solve alot of this, but it's a long story why it's not in place).
The short answer is that <input> elements need some kind of label and that label has to be directly associated with, or "tied to", the <input>. "Proximity" is not a direct association. That is, just because a label is "close" to the input in the DOM, that doesn't tie the two elements together.
Some screen readers will try to look for some text to use as a label if one is not explicitely found, but that usually involves going to the previous sibling of the <input> in the DOM and if that sibling has some kind of text associated with it, then treat that like the label. Sometimes it works and sometimes it doesn't. I would not rely on it.
For example,
<label>password</label>
<p>should contain upper and lower case letters, a number, and a special character</p>
<input>
In this case, the "should contain..." text will be treated as the input's label, which is wrong. It doesn't matter that there is a <label> element prior to the <p>. There is nothing in the DOM tying the <label> to the <input>. The above example should be written as:
<label for="pw">password</label>
<p id="rules">should contain upper and lower case letters, a number, and a special character</p>
<input id="pw" aria-describedby="rules">
This associates both text elements with the input. The <label> is tied directly via the for attribute (and the ID on the <input>) and the description of the password is tied via the aria-describedby on the <input>.
So the first choice of labelling an input should be with native html, if possible. Use the for attribute of the <label>.
Another way to label, as you noted, is using the aria-label or aria-labelledby on the <input> itself. While this will give the input an accessible name for screen readers, it won't help sighted users. The aria-label is not a visible thing. However, in your case, it looks like there is already a visual label (even if it's not officially "tied" to the input).
So, to comment on your four proposals (A-D):
A. You can put aria-label on the parent container but the <input> would still need to be told to look at the parent to retrieve the label, and that's done with aria-labelledby on the <input> (and would require an ID on the parent so you can point to it.).
B. If you put the aria-label directly on the <input>, then yes, you should set aria-hidden="true" on the visible label, otherwise a screen reader user can navigate to the visible label text and then navigate to the input and hear the same text again. But that's an odd solution. If the text is already visible, the best thing is to put an ID on the visible text and associate it with the <input> via aria-labelledby.
C. Worth a short, but no.
D. This is a friendly place so all ideas will be considered, but please do not do this. Do not segregate different types of users or force people to opt-in to an accessible site.
It sounds like your main argument for not creating an accessible solution is the size of your page. Not to be dramatic, but that wouldn't hold up in court. That is, if your site ended up being the defendant in litigation, arguing that you didn't implement accessibility because you didn't want the page load to be larger would not be a valid reason. That's just an implementation problem on your end.
What is the use of the title attribute on a html element?
<div class="myDiv" title="This is the title"> Stuff </div>
Is it intended to be used as a tooltip? Does it have any further use?
Pretty much. The HTML spec calls it advisory text, but it uses the word "tooltip" as well, because that's how it is typically represented:
The title attribute represents advisory information for the element, such as would be appropriate for a tooltip. On a link, this could be the title or a description of the target resource; on an image, it could be the image credit or a description of the image; on a paragraph, it could be a footnote or commentary on the text; on a citation, it could be further information about the source; on interactive content, it could be a label for, or instructions for, use of the element; and so forth. The value is text.
Its role in relation to the content depends entirely on the context given by the content, but in general it serves as optional, supplementary information for that content.
Title attribute is for tool tip. IN title attribute we can pass some text to tell the user for what purpose that particular element is.
This topic is already well explained. But it is important to remember that using the title attribute is not very useful when it comes to HTML accessibility and usability. The use of this attribute is neither recommended by W3C. In W3C words:
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).
If you give an object a Title, try hovering your mouse over it, It will show a subtext which contains the text you set as title.
"The title attribute allows the author to provide extra information about any element on a page."
Typically, this attribute’s content is rendered as a tooltip that appears when the user hovers the cursor over the element to which the title is applied.
Yeah.. It is mainly intended for tooltip... But also we are using for identification.. Whenever two or more divisions are placed one behind other, to identify each one we can use that.....
The title attribute is a descriptor, like the alt attribute for images. It is not required, but would be good practice to use where it makes sense. An old school example might be if you have a table of information on your page. Adding the title attribute to the table tag with a brief notation of what the table is (e.g. 2014 Daytona 500 Race Results) would make sense.
Once upon a time, search engines treated the contents of title attributes as content. I don't believe they do anymore (though I'm not 100% sure) though.
Hope that helps!