Add technique for identifying CSS generated content-images

[alastc]

As discussed in #296, one of the aspects of the Adapting text SC #78 was the ability to change font-family by the user.

That aspect has been removed from Adapting text because it is (or should be) a failure of 1.3.1, i.e. not identifying an element as an image that has the sole purpose of displaying an image.

This would apply to things like font-icons, image backgrounds and before/after pseudo content, e.g. <span class="icon" aria-hidden="true"></span><span class="off-screen">Bookmark</span>

Although it has an accessible name, the icon would disappear if a user over-rides font-family and/or background images.

If an element (like the span above) is identified as an image, then the user stylesheet/script/extension could use this sort of CSS to avoid replacing the icons:

*:not([role="img"]) {
font-family: Comic Sans MS, Georgia,'Times New Roman',serif;
}

This technique would not preclude any particular implementation, so even very simple versions can achieve it quiet easily, e.g: <span class="icon" role="img" aria-label="Bookmark"></span>

The key thing is that an element intended to provide an image is given that role.

The next step is a test page with good & bad variations on this, I've assigned it to myself for now and created this issue to remind me to do it.

@lauracarlson noted there is already a failure under F87 - Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using :before and :after pseudo-elements and the 'content' property in CSS, we could also generate a similar failure for this, but I think a technique first is the way to go.

[patrickhlauke]

for clarity, note that icon font usage is not really "background content images", as the content is not an image in the background, but rather a CSS generated foreground character. suggest changing the title here (and avoiding this inaccuracy in future discussions)

[patrickhlauke]

and actual background images (using CSS background: ... or similar) wouldn't cause any problems for LV users anyway with regards to font substitution, as they don't use any font/text that would be substituted

[patrickhlauke]

split out the issue of LV users explicitly suppressing images (also applies to non-LV users of course) into a separate issue/technique, i'd say, as it feels like currently you're trying to tackle different things under one big umbrella technique/advice (and this aspect is likely more along lines of "how to provide alternative content for CSS background images", which of course also touches on how to do it for AT users etc and relates to 1.1.1, 4.1.2, 1.3.3)

[alastc]

I've tried "identifying CSS generated content-images" instead, but note that if #296 takes effect then font-icons are being added to non-text content.

Actual background Images (e.g. sprites) are also an issue, if you override foreground colours you have to also override background colours, and therefore images. It is also an issue for High Contrast Mode. See the requirements table for more.

The principle is if it looks like a duck, I mean image, smells like an image, it is identified as an image.

Before we split things out, let me do a test page with as many variations as I can think of, and then you can point out some more, and then we can see what fits together.

[patrickhlauke]

I've tried "identifying CSS generated content-images" instead, but note that if #296 takes effect then font-icons are being added to non-text content.

sure, they're non-text content. but they're still not "background content images"

[alastc]

So I didn't include "background" :-)

[lauracarlson]

Hi Alastair and all,

As mentioned, a start of a technique is in the Wiki: Providing a Semantically Identified Icon Font with role=img.

Please test it. I tested in Safari and it seems to work okay there.

Also please, edit at will, add more examples etc.

Thanks, Laura

[lauracarlson]

I added a second example to the Semantically Identifying Icon Font with role=img technique.

Comments and ideas for improvement are appreciated. @alastc please, edit as you see fit.

Thanks, Laura

[patrickhlauke]

On 21/05/2017 15:26, Laura Carlson wrote:

I added a second example to the Semantically Identifying Icon Font with role=img https://www.w3.org/WAI/GL/wiki/Semantically_Identifying_Icon_Font_with_role%3Dimg technique.

Comments and ideas for improvement are appreciated. @alastc https://github.com/alastc please, edit as you see fit.

Removed the aria-hidden="true" attributes, as they'd result in the entire element being hidden, meaning that the aria-label would not be seen by any AT either.

[patrickhlauke]

a more robust and sensible way of doing

<a href="email.html">
 <!-- Icon added visually. Text alternative (which overrides any character that might be used as icon font code point) and role="img" added. -->
 <span class="fa fa-envelope" aria-label="Favorite" role="img"></span>
</a>

would be, in my view, to add the aria-label on the link itself and simply completely hide the icon font, a la

<!-- add aria-label on the link itself -->
<a href="email.html" aria-label="Favorite" >
  <!-- Icon itself completely hidden from AT, so needs no role nor alternative -->
  <span class="fa fa-envelope" aria-hidden="true"></span>
</a>

[alastc]

That's fine for screenreader style AT, but how would a more basic extension know that there is an icon it shouldn't override?

What we're trying to achieve (without disrupting other AT) is to identify icons that are implemented by CSS background or font-icon. Without something (like role=img) how does that work? Hidden text / meta-data isn't useful here.

[patrickhlauke]

[aria-hidden=true]:empty

[alastc]

Hmm, not sure what proportion of implementations that would work for, it feels like there should be a positive thing an author can add to say "this is an image".

[patrickhlauke]

conversely, adding an explicit role to something that's hidden from the accessibility tree feels...slightly off (but as a suggested practice, rather than something normative, i guess it could fly)

[jake-abma]

This would apply to things like font-icons, image backgrounds and before/after pseudo content, e.g. Bookmark

In this case it doesn’t have an accessible name. There is text content present but no programmatic relationship.

Another one, probably mentioned already, but how to convey the hidden accessible name (via aria-label or aria-labelledby) to LV users?

[patrickhlauke]

Another one, probably mentioned already, but how to convey the hidden accessible name (via aria-label or aria-labelledby) to LV users?

to use spec language, that's orthogonal to the problem discussed here i'd say. the image itself is purely decorative, and the accessible name is on the actual control. how aria-label etc on arbitrary elements (not just CSS images, but any other element where it may be used, like form controls, links, etc) can be visually exposed is a separate, broader discussion that should be had.

[alastc]

The problem case is when it is not decorative, but meaningful. Either as an indicator (e.g. a star), or interactive.

If you have low vision and expand things to >200%, the last thing you want to do is replace the icons with their accessible name. Here's a quick example from the BBC zoomed in:

Then replacing top icons with the hidden text:

I didn't try and replace the weather icons, but you get the idea. Replacing the icons with their hidden text breaks the layout, I had to undo a lot of CSS in order to show the text. Without personalisation that doesn't work.

What I'm aiming for a set of methods that work such as:

• Use a foreground img/SVG (which with HTTP2 is not a performance hit so people are moving that way anyway).
• Include text (or rather, if text is included then don't worry about it).
• If you can't do either of the above, then you can use a background image or font icon, but semantically mark your icon as an image. (Kind of like you can recreate a data table with ARIA. Not ideal, but there if you need it.)

I'm working on a test page (starting from Laura's) to try and make a matrix of what works / doesn't work in both screen readers and when over-riding fonts/backgrounds.

I find it interesting that replacing fonts and backgrounds only breaks some of the icons, I've come across a lot of big sites that use different methods for icons (e.g. BBC, Adobe) where some are foreground, some are background. We just need a little push for foreground or semantic fallback.

[lauracarlson]

Hi @patrickhlauke and @alastc ,

Removed the aria-hidden="true" attributes, as they'd result in the entire element being hidden, meaning that the aria-label would not be seen by any AT either.

Thank you, Patrick!

Alastair, I updated the live examples to match the HTML in the Wiki (no aria-hidden="true). If you want to add them to your test page, they are at:

• Semantically Identified Icon Font with role="img"
• Semantically Identified Linked Icon Font

Thanks, Laura

[steverep]

Hi @alastc and @lauracarlson.... Sorry I accidentally unassigned both of you in trying to assign myself as well, and now I can't seem to reassign you both. The widget is not very screen reader friendly.

[lauracarlson]

Hi @steverep and @alastc ,

Sorry I accidentally unassigned both of you in trying to assign myself as well, and now I can't seem to reassign you both. The widget is not very screen reader friendly.

No worries. I fixed the list.

Thanks for wanting to help, Steve. Welcome aboard!

[steverep]

Hi all. So I've been working on an article on this topic because I've done fairly extensive testing. Let me give the highlights and brief rationale:

1. Never use aria-hidden="true" (decorative or not). I know the ARIA spec opened the door here under caution, but it was not done with low vision considerations in mind. First, if not actually hidden visibly, visual focus indicators can get confused (go ahead and try it with VoiceOver as an example), and there's no guidance on what the UA is supposed to do here. Second, no one ever tests screen readers with a mouse, and UAs will still try to present an accessible name if I can hover over it.
2. Always use role="img" (decorative or not), unless CSS has already done this programmatically. It's the only way to identify to AT that it's not text, in the same way that <h1> (or equivalent ARIA) is the only way to programmatically identify a level 1 heading. This should be a 1.3.1 failure. Of course, if background-image is used and the image is actually decorative background, then this is unnecessary.
3. Give it an aria-label (decorative or not). Once we establish that role="img" needs to be present, then the same rules we use for <img> should apply. The only way to give appropriate alt text is via aria-label (maybe aria-labeledby in some cases but I need to test this more). And without this, some AT use will always fail.
   1. For decorative uses, aria-label="" behaves just like alt="" or content: ... / "". The AT skips it in the reading order and ignores it on mouse hover. And, well, this makes sense, right? It's documented to do this for HTML and CSS already, so why not ARIA? The current draft of the Accessible Name calculation document needs to set this in stone (currently it uses "nonempty" when referencing aria-label which we should file a bug on).
   2. For non-decorative uses, perhaps the only alternative other than aria-label I'm seeing suggested is using off screen text, to which I'd ask: Is this acceptable for an <img>? It fails both mouse hover and obviously visual indicator tests.

I think this covers the examples possible given the thread title, but note that we also need to address other issues. H86: Providing text alternatives for ASCII art, emoticons, and leetspeak is a completely insufficient technique for adapting text (and 1.3.1 in my opinion). For example, ASCII art may rely on specific fonts or other styling, so it too would be ruined without role="img".

[alastc]

Hi @steverep, great stuff, I'm glad you've been testing as I'm struggling to fit that in.

I'm not sure what you mean by CSS programatically setting role=img? (In point 2) How would you set that in CSS?

I really like the idea of using aria-label="" instead of aria-hidden, it's one of those so-obvious in hindsight things, why didn't I think of that??

I think we need to be very careful of the term "decorative", because I think there are different things going on under that term. I'm not sure what you meant, but I think there are two cases:

1. Background images (or font-icons) are often considered decorative by definition, however, sometimes they are required for understanding content. That's one of the main scenarios driving this and background don't mean decorative.

2. Supplementary images which have visible text next to them fulfilling the same purpose.

At the top of the edit text-boxes are the editing icons (Bold etc.), which in this case are foreground SVGs (good), but in some websites are background images or font-icons. When done that way they are background images and need to:

• Provide an accessible name for AT (especially screenreaders).
• Not disappear when fonts and backgrounds are overriden.

The top of this page has an "issues" text-link with a little "exclamation" icon next to it, that's a good example of the 'supplementary images' type. That needs to hide any icon generated content (e.g. the character of the font-icon) from screenreader users, but there is no special requirement for LV use.

So going with your suggestion a background image (no visible text) could be:

<span class="icon" aria-label="Favorite" role="img"></span>

One with visible text:

<span><span class="icon" aria-label="" role="img"></span>Favorite</span>

One with hidden text:

<span class="icon" aria-label="" role="img"></span><span class="offscreen">Favorite</span>

I think those combinations could cover any of the background-images and before/after pseudo element methods?

The foreground method used on the buttons above this box is good to (cut down for clarity):

<button aria-label="Edit comment">
        <svg aria-hidden="true" height="16" width="14">
<path ...></path></svg>
</button>

[patrickhlauke]

Never use aria-hidden="true" (decorative or not). I know the ARIA spec opened the door here under caution, but it was not done with low vision considerations in mind. First, if not actually hidden visibly, visual focus indicators can get confused (go ahead and try it with VoiceOver as an example), and there's no guidance on what the UA is supposed to do here. Second, no one ever tests screen readers with a mouse, and UAs will still try to present an accessible name if I can hover over it.

would be interested so see the final article on this. reading this cold, it sounds more like an UA/AT bug, as surely there are situations where aria-hidden="true" should be usable (in general, not just for icon fonts and similar)?

[jake-abma]

Hi @alastc,

<span class="icon" aria-label="" role="img"></span><span class="offscreen">Favorite</span>

should become: <span class="icon" aria-labelledby="favorite" role="img"></span><span class="offscreen" id="favorite">Favorite</span>

Otherwise you’ll have no accessible name for the image and a non-related hidden text. (Even when nested the aria-label would win the calculation)

[jake-abma]

Hi @alastc,

<span><span class="icon" aria-label="" role="img"></span>Favorite</span>

This one is not good practice either, we’ve an empty image read as “image” in VO (no name) followed by a text not programmatically linked. NVDA seems to ignore the image though.

[lauracarlson]

Hi all,

FYI:

Font Awesome' s Accessibility page recommends aria-hidden="true" for some use cases.

Related Issue: https://github.com/FortAwesome/Font-Awesome/issues/6133

[steverep]

I'm not sure what you mean by CSS programatically setting  role=img ? (In point 2) How would you set that in CSS?

Yeah, perhaps a bad way to state what I meant. I simply meant that if you are using CSS background-image, then it's already programmatically an image. The fact that this isn't passed to AT is because there's a decorative assumption. Another way might be content: url(...), and now you've given me something else I need to test because I don't know it that is programmatically presented as an image. I'll check.

@alastc, regarding your discussion of "decorative", I think we're already on the same page. To me, "decorative" means meeting the WCAG 2.0 definition of it, and not just because it's inserted in the background. For example, one inserted using background-image needs to follow the rules as I stated above.

The first 2 examples you provided are just fine, but the others are not.

One with hidden text:  <span class="icon" aria-label="" role="img"></span><span class="offscreen">Favorite</span>

If I mouse over this icon, I'll get no accessible name, and if I want to jump to it via keyboard using "g" in NVDA for instance, it'll be skipped as decorative. This is not a good technique. Using aria-labeledby here would be better, but as I said I need to test this more. It's less reliable than aria-label.

While closer to fully accessible, the foreground SVG method for the edit and delete comment buttons above this box also have the mouse over problem (NVDA tells me "diagram", because yes there is something there not hidden). The accessible name needs to come from the SVG. Rule 1 still applies.

reading this cold, it sounds more like an UA/AT bug, as surely there are situations where  aria-hidden="true"  should be usable (in general, not just for icon fonts and similar)?

Yes, when the content is actually hidden visibly (per the ARIA spec definition for hidden). I fail to see an appropriate use case other than that. Perhaps we could argue that UAs should not be trying to compute an accessible name on aria-hidden="true" content, but I think that would be a bad approach because it would potentially create more accessibility problems when mistakenly used (e.g. what do we tell UAs to do if both aria-hidden="true" and there's a label?). The safer, and consistent approach with HTML and CSS, is to set aria-label="" because it takes an active thought of the author to decide what the name should be or that it should be decorative.

[jake-abma]

Hi,

Not using aria-hidden="true" comes probably from the fourth rule of ARIA which states:

Do not use role="presentation" or aria-hidden="true" on a visible focusable element.

https://www.w3.org/TR/using-aria/#fourth

This because when you ‘see’ something on your screen and trying to focus it but it’s removed from the API with all its consequences.

For a icon it won’t hurt.

[jake-abma]

Better to do something like this:

<span aria-label=“favourite” role="img"> <span class="icon" aria-hidden=“true”></span> </span>

or

<span aria-labelledby=“favourite” role="img"> <span class="icon" aria-hidden=“true” ></span> <span class="offscreen" id=“favourite”>Favourite</span> </span>

or

<span aria-labelledby=“favourite” role="img"> <span class="icon" aria-hidden=“true” ></span> <span id=“favourite”>Favourite</span> </span>

This way the ":before content" isn't read by screen readers (if some of them don't know the character they'll bleep)

And although really ugly, this one makes it all disappear / decorative:

<span role="img" aria-hidden=“true”> <span class="icon"></span> </span>

[jake-abma]

@steverep

Using aria-labeledby here would be better, but as I said I need to test this more. It's less reliable than aria-label.

Aria-labelledby is as reliable and useful as aria-label. You can make a choice of always applying aria-labelledby so it’s part of text in the DOM and when CSS is turned off you’ll see the text (I like this one better more often than aria-label). Aria-labelledby also precedes aria-label in the name calculation.

Adding a title attribute could fix the tooltip IF you want a tooltip.

[jake-abma]

Forgot the CSS font fix...

*:not([role="img"]) > .icon { font-family: Comic Sans MS, Georgia,'Times New Roman',serif; }

[steverep]

@jake-abma, your first and third examples would fail the test to get an accessible name on mouse hover because you still use aria-hidden. The second two aren't going to work because you've told the UA that the text "Favorite" is actually an image, so I'm not sure the text would even be read. You've also complicated font replacement because I need to be more careful about my CSS rule to include all children of role="img". Ultimately, I don't see any advantage here over providing the name and role to the element that inserts the icon, do you?

Adding a title attribute could fix the tooltip IF you want a tooltip.

It's not about a visual tooltip; it's about the accessible name. All screen readers can read what you put the pointer on just as if you were moving focus across it with the keyboard.

Aria-labelledby is as reliable and useful as aria-label. You can make a choice of always applying aria-labelledby so it’s part of text in the DOM and when CSS is turned off you’ll see the text (I like this one better more often than aria-label). Aria-labelledby also precedes aria-label in the name calculation.

As one example, I suggest you put a control in a table then label it using the table headers with aria-labeledby. Different UA and AT combinations will behave differently. They'll all do the same thing with aria-label.

If you want to handle the case with CSS turned off (an extremely rare occurrence these days because so much more will break), then you could just do this:

<div><span role="img" aria-label="favorite" class="icon"></span><span style="display: none">Favorite</span></div>

Using aria-labeledby instead may still work here but would need to be thoroughly tested.

[jake-abma]

@steverep, thanks for the comments, to be more flexible it could work fine (also multiple colored font icons as a stack), as you suggest this would be the way to go for single colored icon fonts:

<span class="icon" role="img" aria-label="favorite"></span>

and

<span class="icon" role="img" aria-label="" aria-hidden="true"></span>

About putting a control in a table, using aria-labelledby, and differences in UA/AT I guess some of them don't follow the name calculation properly. This is know and the makers should fix it.

[steverep]

<span class="icon" role="img" aria-label="" aria-hidden="true"></span>

This is not okay because the presence of aria-hidden="true" makes the visual focus indicator unreliable. If you can see it, it's not hidden. Get rid of that attribute and we're fine.

I guess some of them don't follow the name calculation properly. This is know and the makers should fix it.

It's not always quite that simple, and much of the time it comes down to minimizing expected repetition, which may be a user preference. In the example of a table, should the screen reader tell me the new table column header, and then repeat it because it may be referenced by an aria-labeledby? Many users don't want this, and different combinations handle this differently to accommodate (there are no formal rules here). Often behavior may be altered depending on whether the element has been jumped to directly (e.g. by tabbing) versus being encountered during continuous reading where the referenced element is likely to be close by and create repetition.

[patrickhlauke]

This is not okay because the presence of aria-hidden="true" makes the visual focus indicator unreliable. If you can see it, it's not hidden. Get rid of that attribute and we're fine.

have bugs been filed against AT? again, this sounds like an AT shortcoming/bug to me

[steverep]

have bugs been filed against AT? again, this sounds like an AT shortcoming/bug to me

More likely a browser's job to fix, but why is it a bug? The UA guidelines for ARIA say to remove it from the accessibility tree completely. They don't say to remove it from the tree but make sure it still takes up space visibly. Every definition in various W3C docs uses something like "not visible or perceivable by any user". It's not a bug - it's poor use of ARIA.

[patrickhlauke]

From https://www.w3.org/TR/wai-aria-1.1/#aria-hidden

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.

So, the actual spec that defines the actual attribute does not forbid this use, and there are circumstances (oh, such as this one) where that's arguably the right thing to do (have something visible but not exposed).

So I still say it's a bug with UA/AT

[steverep]

@patrickhlauke, I noted in my original comment that the cautionary note you quoted ought to be removed. It takes a binary approach to visual impairments - blind or not blind. Please give me a single example where all information continues to be provided to me when using it on something visible, and that means it has to be accessibility supported per WCAG. I'd be happy to take that statement back if you do and it can't be addressed simply with aria-label="".

We might just have to agree to disagree that there's an appropriate use case here, but I don't understand why you would want to change all current UA/AT behavior when a a perfectly analogous technique of aria-label="" is already pretty well supported from my tests. Removing that note in ARIA is a lot simpler than trying to complicate the world by creating another option where you'd then have to clarify conflicts and have UA/AT do even more work.

[patrickhlauke]

I noted in my original comment that the cautionary note you quoted ought to be removed.

i'd suggest getting filing an issue against the ARIA spec then.

Please give me a single example

I could give you many examples, but I'm sure your response would be "they should code it this way rather than that way", and we'd end up in a nice circular discussion. I'd say at this stage getting the ARIA spec amended first would be a better use of our time.

but I don't understand why you would want to change all current UA/AT behavior

because UAs and ATs should behave according to what the specs say, and the currently valid spec (as well as the previous ARIA 1.0 from 2014 https://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden) make it fairly clear currently that authors may do this, so UAs and ATs should behave in line with that.

[steverep]

The point of examples was not to get into a circular discussion; I'm simply looking for an example where using it doesn't currently break the way some low vision users operate effectively with their AT. The door may be open for authors under caution, but the guidance for UA/AT is missing.

To your point, I agree a bug needs to be filed against ARIA, so I did. See w3c/aria#583.

[jake-abma]

@steverep

This is not okay because the presence of aria-hidden="true" makes the visual focus indicator unreliable. If you can see it, it's not hidden. Get rid of that attribute and we're fine.

Problem is we don’t want the image to be announced, it’s decorative and we don’t want the character to bleep.

This is why I proposed the other solution which also serves as a place holder for multi coloured font icons out there (also a lot!).

Also if you can't 'get to it' with your screen reader that is the same as when using a background image OR when you leave the alt attribute empty on an image (also removed from the tree)

[jake-abma]

So to wrap it up a bit in an overview:

With spoken text

<span class="icon" role="img" aria-label="favorite"></span>

Hidden for AT (won't 'focus' with arrow keys / screen readers)

<span class="icon" role="img" aria-hidden="true"></span>

Stacked multi color with spoken text

<span role="img" aria-label="favourite">
    <span class="icon color-1" aria-hidden="true"></span>
    <span class="icon color-2" aria-hidden="true"></span>
</span>

Stacked multi color with aria-labelledby

<span role="img" aria-labelledby="favourite">
    <span class="icon color-1" aria-hidden="true"></span>
    <span class="icon color-2" aria-hidden="true"></span>
    <span class="offscreen" id="favourite">Favourite</span>
</span>

Stacked multi color and aria-labelledby multiple sources

<span role="img" aria-labelledby="favourite thing">
    <span class="icon color-1" aria-hidden="true"></span>
    <span class="icon color-2" aria-hidden="true"></span>
</span>

<span id="favourite">Favourite</span>
<span id="thing">Thing</span>

This follows the same pattern as can be seen at:

https://www.w3.org/WAI/GL/wiki/Using_aria-labelledby_to_provide_a_text_alternative_for_non-text_content#Example_2

https://www.w3.org/TR/WCAG20-TECHS/ARIA9.html

And then the CS:

For single icons:

*:not([role="img"]) {
font-family: Comic Sans MS, Georgia,'Times New Roman',serif;
}

For stacked multi colored icons:

*:not([role="img"]) > .icon {
font-family: Comic Sans MS, Georgia,'Times New Roman',serif;
}

Or always use the multi color construction for clarity and yes it gets a bit messy but 1 solution for all is not feasible.

[jake-abma]

Please also note: https://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html#text-equiv-all-techniques-head

Techniques to indicate that text alternatives are not required for Situation F:

C9: Using CSS to include decorative images https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/C9

H67: Using null alt text and no title attribute on img elements for images that AT should ignore https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/H67

The font icons follow the same path and fall under “Sufficient Techniques” (the ARIA equivalent)

[mraccess77]

I don't think aria-label="" is useful because it doesn't convey anything. It should be skipped over by the name calculation and do not indicate something is decorative. aria-hidden true should cover that.

[jake-abma]

@mraccess77 thanks, adjusted in example...

[alastc]

@jake-abma wrote:

Otherwise you’ll have no accessible name for the image and a non-related hidden text. (Even when nested the aria-label would win the calculation)

Ah, I should have said that one makes sense only when inside a link, so it's:

<a href="something">
 <span><span class="icon" aria-label="" role="img"></span>Favorite</span>
</a>

Then the hidden text is the accessible name.

On the same example, @steverep said:

If I mouse over this icon, I'll get no accessible name

Is that true if it's within a link? Then the text becomes the name, and the link is the thing you hover over (onscreen).

Regarding aria-hidden, I'm not saying it is good practice, but in this context I've seen it used to hide rubbish like font-icons. So there would be visible text, and the visible icon is within an aria-hidden.

If that is changed at the spec level, there will be a lot of non-conforming content (like this github page) that does generally work.

Regarding @jake-abma's examples, that's good, I'd just point out that the CSS bit (*:not([role="img"])) was intended to be for the user to apply, i.e. so they can avoid removing images needed to understand the content.

[mraccess77]

F38 https://www.w3.org/TR/WCAG20-TECHS/F38.html indicates that role presentation should be used for decorative images. Since ARIA doesn't allow for multiple roles and I believe aria-label="" or even alt="" is ambiguous, and aria-hidden can cause some issues with visual indication we don't have an optimal solution using current specifications.

[steverep]

Hi @mraccess77 and @jake-abma:

I don't think aria-label="" is useful because it doesn't convey anything. It should be skipped over by the name calculation and do not indicate something is decorative. aria-hidden true should cover that.

Problem is we don’t want the image to be announced, it’s decorative and we don’t want the character to bleep.

Hidden for AT (won't 'focus' with arrow keys / screen readers)  <span class="icon" role="img" aria-hidden="true"></span>

Instead of repeating myself, please see my original comment above. In short, aria-label="" is NOT skipped over by most UAs and instead behaves just like alt="", and aria-hidden="true" does NOT work in practice for accessible names on mouse over or for some focus indicators whenever it is used on visible content. Let's please focus on what works in practice (i.e. has good accessibility support), and not what we presume should work.

Hi @alastc:

Is that true if it's within a link? Then the text becomes the name, and the link is the thing you hover over (onscreen).

I'm not sure if I follow what you're asking because the example this followed above has no hidden text (was Favorite supposed to be hidden?). As it stands, hovering over the icon will do nothing (typical of a decorative image), and hovering over Favorite will just say Favorite.

[patrickhlauke]

aria-hidden="true" does NOT work in practice for accessible names on mouse over or for some focus indicators whenever it is used on visible content.

just so that folks can get a clearer first-hand picture of the problems you're describing, what browser/AT combinations (and any specific settings) is this causing the problems you mention?

[alastc]

I've fleshed out that test page.

@steverep I meant something like example B3 or B4 on that page, where they are both within a link.

I still need to test in NVDA and/or Jaws, but I was surprised VoiceOver didn't read any of the font-icon 'characters' out, I thought it would. Maybe I'm remembering NVDA, and VO doesn't read CSS generated content?

Examples A6, B6 and C6 are with aria-label="" instead of aria-hidden, seems to work ok, although VO reads out "Link, image, [name]" so it is a little busy, but it works there.

I also need to add a set of examples for background images instead, but that shouldn't be as difficult as the font-icon scenario.

From a dev point of view, my favourite is probably this one for links with text (c6):

<a href="#">
   <span role="img" class="fa fa-star" aria-label=""></span>Favourite
</a>