You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From ARIA24:
"The objective of this technique is to show how to semantically identify an element that uses a font file for icons. When a user overrides font-family these icons typically disappear unless there is a means to identify them. The point is to provide a technique to differentiate icon fonts from general font (text) usage.
Some low vision users need user stylesheets, scripts, or extensions to override the fonts on a page to perceive text content. However, they need to be able to perceive icon fonts that are meaningful, such as a star signifying a favorite, or an email icon in a link.
The key is for the author to semantically markup icon fonts with role="img". Then the user's font replacement selector can hook into that semantic and exclude role="img". This results in those icon fonts being shown."
This technique with semantic markup in author stylesheets does not necessarily result in icon fonts being shown. If a script, extension, or browser overrides the font with no specific selector or regard for font icons then this technique does not solve this issue. This is evident in IE11 when ignoring font styles under their accessibility settings.
The text was updated successfully, but these errors were encountered:
JayJune
changed the title
ARIA24 is vaguely explained and the technique does not necessarily solve the issue.
ARIA24 technique does not necessarily solve the issue.
Jun 29, 2020
The technique assumes that the fonts are not replaced in general (as in IE 11), but it also assumes that the user knows the selector with which the replacement of the font icons can be excluded. I think the second one is more problematic.
In my opinion, the technology of ARIA24 is hardly established so far, so that even web users do not know and use it.
I also agree that ARIA 24 is problematic because you can't just apply role of img to something that may already have a a semantic role like link or button. I use Stylish and have difficult properly changing the font without messing up font icons. While role img might help if use for some it doesn't fully address the issue.
@mraccess77 Hi Jon, just curious: what's problematic about having role=img specified for a font icon container sitting inside an a element (with native role link)? as in example 3 of ARIA24?
If the concerns are valid, is the suggestion to downgrade this Technique from 'sufficient' to 'advisory'? And would that mean any and all uses of font icons will fail 1.3.1?
From ARIA24:
"The objective of this technique is to show how to semantically identify an element that uses a font file for icons. When a user overrides font-family these icons typically disappear unless there is a means to identify them. The point is to provide a technique to differentiate icon fonts from general font (text) usage.
Some low vision users need user stylesheets, scripts, or extensions to override the fonts on a page to perceive text content. However, they need to be able to perceive icon fonts that are meaningful, such as a star signifying a favorite, or an email icon in a link.
The key is for the author to semantically markup icon fonts with role="img". Then the user's font replacement selector can hook into that semantic and exclude role="img". This results in those icon fonts being shown."
This technique with semantic markup in author stylesheets does not necessarily result in icon fonts being shown. If a script, extension, or browser overrides the font with no specific selector or regard for font icons then this technique does not solve this issue. This is evident in IE11 when ignoring font styles under their accessibility settings.
The text was updated successfully, but these errors were encountered: