I want to have aria-label in span get announced. I did a lot search, found a solution that add role="img". However, in this way, the "image" word will also be announced. I am wondering if there is a hack way to only announce the aria-label or aria-description for span?
For example, I want "123" to be announced:
<span aria-description="123">456</span>
The aria-label is sometimes ignored by some assistive technology if the element you put it on doesn't have any semantic meaning. A <span> doesn't have semantic meaning. If you add a role that is appropriate for your description, then it should be read correctly.
Related
What exactly can aria-label be used on?
I have found documentation that shows it can be used on interactive items (such as <button> for example), but can it be used on any of the following:
<p>, <span>, <li> or <abbr>?
I am trying to have particular words and abbreviations within a paragraph, read out as something specific (eg: Aussies read out as "Ozzies" instead of "Ossies" or "NSW" read out as "New South Wales")
Testing in Microsoft Edge, Google Chrome, Mozilla Firefox (all Windows 10) and iPhone Safari (iOS)
You should generally not use aria-label on static content. It's only intended to be used on interactive elements and some sectioning elements.
https://www.w3.org/TR/using-aria/#practical-support-aria-label-aria-labelledby-and-aria-describedby
aria-labelledby and aria-describedby are robustly supported for interactive content elements such as links and form controls including
the many input types.
For most assistive technology it's fine to use aria-label or aria-labelledby on the <nav>, and <main> elements but not on
<footer>, <section>, <article>, or <header> .
There is mixed support for aria-label or aria-labelledby on <aside>.
Talkback on Android overrides the content of all landmarks with aria-label or aria-labelledby.
Its fine to use aria-label or aria-labelledby on div elements with role=navigation, role=search, role=main, JAWS doesn't
support them on role=banner, role=complementary,
role=contentinfo. NVDA, VoiceOver, and Talkback are OK
aria-label, aria-labelledby and aria-describedby work well on table, th and td elements with a few exceptions for NVDA,
VoiceOver on iOS, and Talkback discussed in next section.
Don't use aria-label or aria-labelledby on any heading elements because it overrides them on NVDA, VoiceOver and Talkback. JAWS
ignores them.
Don't use aria-label or aria-labelledby on any other non-interactive content such as p, legend, li, or ul, because
it is ignored.
Don't use aria-label or aria-labelledby on a span or div unless its given a role. When aria-label or aria-labelledby are
on interactive roles (such as a link or button) or an img role, they
override the contents of the div or span. Other roles besides
Landmarks (discussed above) are ignored.
Keep in mind that the above guidance was written in 2018, and support has likely improved among some browsers, but the advice above is still safe, and I would recommend mostly following it.
Thanks to brennanyoung for passing along this great article from Steve Faulkner:
https://html5accessibility.com/stuff/2020/11/07/not-so-short-note-on-aria-label-usage-big-table-edition/
It's worth mentioning that the above test results are more recent than the advice given by W3C at the beginning of my post, and it does contradict the W3C advice in some places.
Additional Resources:
http://www.davidmacd.com/blog/does-aria-override-static-backup.html
https://a11ysupport.io/tech/aria/aria-label_attribute
Attributes aria-label and aria-labelledby are typically used and correctly recognized only on interactive elements such a buttons, form fields, links, etc.
They usually don't work, i.e. not read or shown, when they are used on non-interactive elements such as <p>, <div>, <li>.
You can use aria-label or aria-labelledby on a <p>, <li>, but it will work only if it's interactive.
The definition of interactive is quite simple: it means something you can interact with. More technically, it basically means focusable.
Note that with some browsers and/or screen readers, aria-label on elements that aren't naturally focusable may only work when navigating in form mode but not in browse mode.
BY naturally focusable, I mean elements that don't need an explicit tabindex to be interactive.
The element <abbr> is a special case. The expanded meaning must be present in the title attribute and not aria-label.
It's most likely an attribute to help people with disabilities and the elderly. (e.g. screen readers) attach a label to an otherwise anonymous HTML element.
Usually search input field does not have visual label (thanks to designers). aria-label can be used to communicate the label of control to screen reader users.
When user focus on both button(by pressing tab) with area label — you can hear focusing on first x button — will tell you only x button but in case of second x button .. you will hear back to the page button only..
<button title="Close"> X </button>
<button aria-label="Back to the page" title="Close" > X </button>
i hope it helps.
you can read further information here https://www.aditus.io/aria/aria-label/
Context: Educational ebook (HTML + CSS) publishing
I have a composition title where I have a sentence like this:
<p>This is <del>correct</del> <ins>incorrect</ins></p>
And it is important that the user knows that some text is being deleted and some text is being inserted. I also have a related scenario where text has a highlight applied that has semantic meaning. For instance:
<p>This is an <span class="highlight-blue">adjective</span> and this is a <span class="highlight-red">noun</span>. </p>
I was recommended to use role="region" + aria-label for these situations by an accessibility consultant.
For instance:
<p>This is an <span role="region" aria-label="adjective" class="highlight-blue">adjective</span> and this is a <span role="region" aria-label="noun" class="highlight-red">noun</span>. </p>
The flexibility is necessary here because we are using a standard CSS for all of our titles and sometimes a highlight-red might indicate passive voice or it might indicate a noun, etc.
I have seen in other questions on this site that it is not allowed to use aria-label on span (or div) elements. Also using Chromevox, I have found that the reader will read the aria-label but not the text inside the aria label. (I do not have access to other screen-readers for testing.)
So my question is: What is the best way to have the semantic meaning of these inline elements read to the screen reader user?
Non-viable options
Pseudo-element with CSS hiding. I've seen solutions where you can create a pseudo-element and then hide it offscreen using CSS. When you hide content off-screen, Kindle encounters issues, dropping large chunks of text after the off-screen content, so this is not a viable option.
I would not make the highligting marks a region. That makes them a landmark, which are used to navigate to different areas on the page. The more landmarks you have, the less useful they are (because you'd have to navigate through a bunch of them to get where you want.).
There's a nice article on making highlights and other editing symbols accessible on "Short note on making your mark (more accessible)"
it is not allowed to use aria-label on span (or div) elements
That's not quite accurate. aria-label is a global attribute and can be set on any element. However, the label might be ignored if set on a <div> or <span>. See "2.10 Practical Support: aria-label, aria-labelledby and aria-describedby". In particular, the third last bullet point:
Don't use aria-label or aria-labelledby on a span or div unless its given a role.
So if your <div> or <span> has a role that is appropriate, then the aria-label will be read. But don't assign a role just to get the aria-label read. The role has to make sense.
In table cell I have a <span> element, that is styled as image and displays state of interface (Enabled/Disabled/Error), based on it's color.
For users with proper vision, it is compact and understandable. I don't want to change it. But as there is no text in this span, it is not read by screen reader. (understandable, but problem)
What is the correct approach to handle such elements for screen readers?
Expected solution would be to add aria-label with text for screen reader, but, as I found in other topics, "aria-label does not work on <div> nor <span>". As I tested it on JAWS 15, it is true, but in JAWS 18 such labels are being read just fine (why?).
Also I tried to add role="img" to this span, and to add text in aria-label and/or alt and/or title with no result in JAWS 15.
What do you mean by "normal users"? Are you talking about sighted users compared to low-vision users? The latter are normal users too.
For low-vision users, yes, an aria-label is normally the way to go. Thank you for considering accessibility issues.
But you'll also have an issue for color deficient users. Those that can't distinguish between certain colors. Is color the only means for conveying the state of the object? Is there an associated icon too? Color-deficient users won't be using a screen reader so won't benefit from an aria-label.
It's not clear in the html or aria specs on the default role of a <span>. The aria-label should be used in the accessible name calculation and step 2D says only if the element is presentational (meaning role='presentation' or role='none') should the aria-label be ignored. So, if a <span> is considered presentational, then its aria-label will be ignored. JAWS seems to be interpreting it this way but NVDA does not. NVDA in firefox will read the aria-label of a <span>.
So your best choice might be to give the <span> a role, such as role='img' or role='note', so that you can give it an aria-label too, but that will also cause the role of the span to be announced.
Or as one commented above, use a real <img> with alt text.
I have a span which serves as a button which is inside a header:
<h3 aria-label="Header Aria Label">
<span tabindex="0" aria-label="Span Aria Label">Button</span>
</h3>
However, whenever I tab to the span, it reads "Header Aria Label". How do I force JAWS to read the aria-label in the span?
First of all, please don't be offended but what you are doing is poor design, at least, accessibility-wise.
A button inside a heading (not a header, BTW, in HTML 5 there is a separate <header> element which is a quite different thing from <h3> you use here) is a bad idea. Really.
But anyway, if you want JAWS to treat your span as a button, either:
Use a native <button> element, or
Use role="button" on your span, otherwise JAWS wouldn't know in any way that this particular span should be treated as a button. But please prefer the first method unless you absolutely have to use a span here. And please, pull it out of your h3, this will be far more accessible.
A span is neither landmark nor interactive content. An aria-label will not be read by a screen reader (and rightly so).
Instead, use a <button> element. That will address your problem, and be more accessible.
I encounter similar issues to this. From my experience it doesn't seem to make any difference whether it's a span, a div or other tag. Even when multiple aria attributes are applied such as role and aria-hidden="false", the aria-label is not always read out. To me, the condition for aria-labels to be read by JAWS seems to be based on some other rule(s). It would be helpful to see the conditional flow of when an aria-label is read by JAWS. I'm guessing only someone with access the the JAWS source code would really be able to answer this. In the meantime I'll keep trying different things to try to get it to work. JAWS finds the element in the DOM, because it can read the inner html (such as reading the word "Button" in the example above). I'm wondering if the decision to read the aria-label is based on it's parent structure, roles and attributes.
I use font-awesome and display their fonts like that:
<i class="icon-lock"></i>
This will display a nice little lock symbol. For the user to know what exactly that means, I tried adding attributes such as title and alt, but to no avail.
Is there any attribute I can use for the <i> tag that executes the same task as alt for images and title for links?
You can use the title attribute on an i element, like any element, e.g.
<i class="icon-lock" title="This symbolizes your being locked inside"></i>
Whether it helps is a more difficult issue. Browsers usually show the title attribute value as a “tooltip” on mouseover, but why would the user mouse over the icon? And such tooltips are of poor usability; so-called CSS tooltips often work better.
Screen readers may give the user optional access to title attributes, but I’m not sure what they do with elements with empty content.
With the advance of WAI-ARIA, when using font icons, you probably should use a combination of the following to improve accessibility:
The role presentation to remove implicit native role semantics of the element. This is especially important if you (ab)use an element with a native semantic to provide icons, as this is the case in your example using the i element (which, according to the specs, "represents a span of text in an alternate voice or mood [...]").
An aria-label to provide a string value that labels the element -or- a native HTML title attribute if you are OK with the browser displaying a tooltip when hovered.
An aria-hidden attribute to hide generated content from assistive technologies (as you are using an icon font family, there is a generated character :before of :after). According to the specs:
Authors MAY, with caution, use aria-hidden to hide visibly rendered
content from assistive technologies only if the act of hiding this
content is intended to improve the experience for users of assistive
technologies by removing redundant or extraneous content. Authors
using aria-hidden to hide visible content from screen readers MUST
ensure that identical or equivalent meaning and functionality is
exposed to assistive technologies.
I don't know your exact use case, so I take the liberty to use the simpler case of providing a phone number. In decreasing order of preference, I would use:
<span aria-label="Our phone number">
<span class="icon-phone" aria-hidden="true"></span>
+33 7 1234576
</span>
(or any variation implying:
- an `i` element with a `role` presentation attribute
instead of the inner `span` element
- a `title` attribute instead of an `aria-label` attribute)
<span class="icon-phone"
aria-label="Our phone number">+33 7 1234576</span>
(or any variation using `title` instead of `aria-label`)
<i class="icon-phone" role="presentation"
aria-label="Our phone number">+33 7 1234576</i>
(or any variation using `title` instead of `aria-label`)
Please note that aria-label and title attributes should describe the content of the element. Not the next sibling element. So I feel like the following solution is not in accordance with the specs (even if most accessibility tools would actually have the same observable behavior as if the phone number were actually inside the span element) :
<span class="icon-phone"
title="Our phone number"></span>+33 7 1234576
You should use <span> or something along those lines instead. You can use the title="" attribute to give some text on hover, if that's what you're looking for. As far as providing accessability to screen readers, or SEO value, you could add the following CSS:
.icon-lock{
text-indent:-99999px;
}
And then write your markup like so:
<span class="icon-lock">What I want the screen reader to say</span>
I think the role for fonts that act like images should be reserved to role="img". This can then be used with aria-label="alt-text". It works because of the ARIA Accessible Name algorithm. See: Aria Techniques Using Img Role.
<i> tags are for marking up text. You are changing the semantic meaning of this tag to something that has nothing to do using italics (and even the italic tag is a bad idea).
You should be using a SPAN instead.
Italic elements do not support alt attributes, IMG elements do. If you want an ALT attribute, use an image.