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.   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.  I'd like to bring this up to the larger group -- but I do have concerns about this.  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.

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 12:49:05 UTC