RE: Icon fonts - semantic elements

Correcting my critique of Jonathan's example to *improbable* and not *impossible*.  I suppose if someone only had a few icons in their font and used the codes instead of classes, they could do the following:

<div class="my-tree-item" role="treeitem">My Tree Item</div>

.my-tree-item::before {
 Font-family: Icon-Font;
 content: \Code-for-Icon / "my icon label";

Here the *bug* doesn't lie with HTML, ARIA, or WCAG, but instead with CSS.  A method is given to provide a name, but it is impossible to specify a role.

I'm thinking we can deal with an edge case like that with carefully crafted techniques, and perhaps an extra failure.


-----Original Message-----
From: Repsher, Stephen J 
Sent: Wednesday, May 17, 2017 10:33 AM
To: Jonathan Avila <>; public-low-vision-a11y-tf <>
Subject: RE: Icon fonts - semantic elements

In my opinion, SC 1.3.1 is already met by providing aria-label or CSS off-screen text that is near/as subtree of the icon/icon link and conveys the same meaning.   
[Steve] Yes but that's 1.1.1 and not 1.3.1, right?  If 1.3.1 requires providing other structural content programmatically such as headings, lists, or tables, then why not images?

The potential violation would be under SC 4.1.2. for the missing role.  But given that aria-label exists as text and CSS off-screen text may exist as text I'm not so sure this will pass as text doesn't really need a role.  
[Steve] I don't follow the logic here since the role is referring to the image/icon, not its text alternative.  That said, 4.1.2 is clearly scoped to controls and I think the SC needs to be changed to cover other structure.  As I've pointed out, I'm not even sure the wording covers control containers like role="toolbar".

I'd like to bring this up to the larger group -- but I do have concerns about this.  
[Steve] I agree... not ready for prime time yet.

For example, sometimes pseudo content is used to display content such as a disclosure triangle of a tree item.  This pseudo content may have an equivalent already in aria-expanded, etc. and the pseudo content may be on another item with an existing role like tree item.  In this case we can't simply add role img and the information is already communicated programmatically. So we need to consider all of the potential cases.
[Steve] If I'm following your example correctly, you mean this:

<div class="my-tree-item" role="treeitem">My Tree Item</div>

.my-tree-item::before {content: ICON }

If so, it would be impossible to use a font to insert the icon here because changing the font family would ruin the display of the entire element, i.e. "My Tree Item".  When icon fonts are inserted with pseudo, they have to be their own element since the font needs to be changed and each icon has its own class, and that's the element that needs role="img".  If it's inserted using the URL to an image file, that's a completely different scenario.

Jonathan Avila

-----Original Message-----
From: Laura Carlson []
Sent: Wednesday, May 17, 2017 7:48 AM
To: Alastair Campbell; Repsher, Stephen J; Jim Allan
Cc: public-low-vision-a11y-tf
Subject: Re: Icon fonts - semantic elements

Hi  Alastair, Stephen, Jim, and all,

Good question, Alastair.  If we can't associate James' technique with
2 SCs we could write up slightly different variations of the techniques for 1.3.1 and 4.1.2.

Question: Last year I wrote some techniques for Icon Fonts and for Unicode Characters that never got accepted by the AGWG. Do we want to want to edit/adjust/pursue any of them as part of this? The following are what are in the Wiki:

Icon Font with an On-Screen Text Alternative

Using aria-hidden=true on an icon font that AT should ignore

Unicode Character with an On-Screen Text Alternative

Using aria-hidden="true" on Unicode characters that AT should ignore

If we don't want to pursue them, we could recycle parts of them for James' technique.



Kindest regards,

On 5/17/17, Alastair Campbell <> wrote:
> I agree, I think we can write a failure (and a positive technique) and 
> associate it with two SCs though?
> At least we can start there.
> Cheers,
> -Alastair
> On 17/05/2017, 01:28, "Repsher, Stephen J" 
> <>
> wrote:
>     I think we need to pursue both avenues - 1.3.1 and 4.1.2.
>     Every other look I take, I don't see how it's not a failure 
> already for 1.3.1.  An icon in the presentation has 2 pieces of 
> "information" associated with it:
>     1. What it means or does, which must be provided programmatically 
> using an aria-label
>     2. The fact that it's an image, which can only be conveyed 
> programmatically using role="img".  The only way to make this 
> available in text would be to add it to the label (e.g.
> aria-label="Image: W3C logo"), but that's a tiny loophole.
>     What am I missing that this isn't already a 1.3.1 failure?
>     Steve
>     -----Original Message-----
>     From: Laura Carlson []
>     Sent: Tuesday, May 16, 2017 4:56 PM
>     To: Repsher, Stephen J <>; Alastair 
> Campbell <>; Jim Allan <>
>     Cc: public-low-vision-a11y-tf <>
>     Subject: Re: Icon fonts - semantic elements
>     Hi Steve, Alastair, and all,
>     On 5/16/17, Repsher, Stephen J <> wrote:
>     > I don’t necessarily disagree, but how did you resolve it would be a
>     > failure for non-UI components?
>     Do you mean maybe Jim still  should open an HTML Issue for a 
> violation of 1.3.1 for  non-UI components?  Alastair previously 
> suggested 1.3.1 and said until that is implemented in HTML, we don't 
> have a standard for authors or user agents. So we would have nothing 
> for WCAG to hook into for conformance [1].
>     Thanks.
>     Kindest Regards,
>     Laura
>     [1]

>     --
>     Laura L. Carlson
>     --
>     Laura L. Carlson

Laura L. Carlson

Received on Wednesday, 17 May 2017 15:18:35 UTC