Jon Avila will investigate.

Change third step of F3 test to:
"If an image does convey important information, the information is provided to assistive technologies and is available visually when the CSS image is not displayed".

Response to commenter: We agree the text of step 3 of the procedure needs to updated to clarify that per WCAG SC 1.1.1 the information needs to be communicated visually when the CSS image is not displayed. The phrase "both programmatically" would be redundant as the check already requires access by assistive technology.

Surveyed on March 24, 2015. Left open for further discussion.

Suggested changes at: https://github.com/w3c/wcag/pull/120/files?diff=split

The focus of F3 IMO is when the user has configured viewing preferences in a manner that CSS images are not displayed possibly even, without disabling author supplied CSS.
And it is likely the user may not be using any AT or is using AT that supports ARIA as well as screen readers do.
If this is the case, should the equivalent text for the CSS image be available to the user in a manner that conveys any association that was apparent when the image is displayed?
Example: Consider an error icon next to a form control and multiple controls have failed validation.
If the text is simply "Error" for every icon, can the user say with which control each error icon is associated: the previous control or the next one?
This is different from an ARIA method that allows for text to be programmatically determinable say for screen readers users.

There is another dimension with CSS images: one cannot use image navigation unless the container for the CSS image has role=image with an aria-label for text equivalence.
Does it fail CR-4 because functionality that is available when standard HTML image is used is no longer available?

(adding my comments from the survey)
This failure was quite simple initially in that it focused on the fact that there is no way to programmatically associate a text alternative with a CSS background image, and was therefore a clear SC 1.1.1 failure if the image was content-bearing. (it is a little dicey when dealing with an image with content but for which the content is repeated in an accessible way on the same page)

I'm inclined to agree that a 1.1.1 failure isn't created when the visual image isn't displayed as a result of CSS being turned off. I do definitely agree that this is a problem for users, but don't think that we can add this to 1.1.1.

I hate to suggest that this might be part of 1.3.1, but it is an uncomfortable fit anywhere so we need to make sure that this is clearer moving forward if we can't resolve where this fits within WCAG 2.0.

Ø If the text is simply "Error" for every icon, can the user say with which control each error icon is associated: the previous control or the next one?

I agree this is an issue, I’ve always been struck by the definition of text alternative which indicates the text alternative must be associated with or refer to the non-text content.

text alternative
Texthttp://www.w3.org/TR/2008/REC-WCAG20-20081211/#textdef that is programmatically associated with non-text contenthttp://www.w3.org/TR/2008/REC-WCAG20-20081211/#non-text-contentdef or referred to from text that is programmatically associated with non-text content. Programmatically associated text is text whose location can be programmatically determined from the non-text content.
Example: An image of a chart is described in text in the paragraph after the chart. The short text alternative for the chart indicates that a description follows.
Note: Refer to Understanding Text Alternativeshttp://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-text-alternatives-head for more information.

Ø There is another dimension with CSS images: one cannot use image navigation unless the container for the CSS image has role=image with an aria-label for text equivalence.
Does it fail CR-4 because functionality that is available when standard HTML image is used is no longer available?
Seems like this could be brought up under SC 1.3.1 or 4.1.1. Historically to my knowledge people have not flagged this but I have seen some cases where AT respond differently when the role is added – so there could be an accessibility supported issue as well if role is not indicated.

Jonathan

Seems like this could be brought up under SC 1.3.1 or 4.1.1.
Do you mean 4.1.2?
In which case, we can have an ARIA technique that demonstrates use of
role=image for CSS background images or the error-icon types.
And maybe a failure when this is not done?
Thanks,
Sailesh

On 1/5/16, Jonathan Avila notifications@github.com wrote:

Ø If the text is simply "Error" for every icon, can the user say with which
control each error icon is associated: the previous control or the next
one?

I agree this is an issue, I’ve always been struck by the definition of text
alternative which indicates the text alternative must be associated with or
refer to the non-text content.

text alternative
Texthttp://www.w3.org/TR/2008/REC-WCAG20-20081211/#textdef that is
programmatically associated with non-text
contenthttp://www.w3.org/TR/2008/REC-WCAG20-20081211/#non-text-contentdef
or referred to from text that is programmatically associated with non-text
content. Programmatically associated text is text whose location can be
programmatically determined from the non-text content.
Example: An image of a chart is described in text in the paragraph after the
chart. The short text alternative for the chart indicates that a description
follows.
Note: Refer to Understanding Text
Alternativeshttp://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-text-alternatives-head
for more information.

Ø There is another dimension with CSS images: one cannot use image
navigation unless the container for the CSS image has role=image with an
aria-label for text equivalence.
Does it fail CR-4 because functionality that is available when standard HTML
image is used is no longer available?
Seems like this could be brought up under SC 1.3.1 or 4.1.1. Historically
to my knowledge people have not flagged this but I have seen some cases
where AT respond differently when the role is added – so there could be an
accessibility supported issue as well if role is not indicated.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com
703.637.8957 (o)
Follow us: Facebookhttp://www.facebook.com/#!/ssbbartgroup |
Twitterhttp://twitter.com/#!/SSBBARTGroup |
LinkedInhttp://www.linkedin.com/company/355266?trk=tyah |
Bloghttp://www.ssbbartgroup.com/blog | Newsletterhttp://eepurl.com/O5DP

From: spanchang [mailto:notifications@github.com]
Sent: Tuesday, January 05, 2016 9:29 AM
To: w3c/wcag
Cc: Jonathan Avila
Subject: Re: [wcag] Clarify the meaning of "is also available" in step #3 of
F3 test (#80)

The focus of F3 IMO is when the user has configured viewing preferences in a
manner that CSS images are not displayed possibly even, without disabling
author supplied CSS.
And it is likely the user may not be using any AT or is using AT that
supports ARIA as well as screen readers do.
If this is the case, should the equivalent text for the CSS image be
available to the user in a manner that conveys any association that was
apparent when the image is displayed?
Example: Consider an error icon next to a form control and multiple controls
have failed validation.
If the text is simply "Error" for every icon, can the user say with which
control each error icon is associated: the previous control or the next
one?
This is different from an ARIA method that allows for text to be
programmatically determinable say for screen readers users.

There is another dimension with CSS images: one cannot use image navigation
unless the container for the CSS image has role=image with an aria-label for
text equivalence.
Does it fail CR-4 because functionality that is available when standard HTML
image is used is no longer available?

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/80#issuecomment-169016194.

---

Reply to this email directly or view it on GitHub:
#80 (comment)

Ø >>Seems like this could be brought up under SC 1.3.1 or 4.1.1.
Do you mean 4.1.2?
Yes, my mistake.

In which case, we can have an ARIA technique that demonstrates use of
role=image for CSS background images or the error-icon types.
And maybe a failure when this is not done?

We’d need to define a technique where knowing the role information was necessary such as when instructions referred to images or something like that.

Jonathan

We’d need to define a technique where knowing the role information was necessary such as when instructions referred to images or something like that.
I really do not think it is very different from the criterion for SC
1.1.1 which requires authors to distinguish an informational image
from a decorative image.
So when a CSS image used as a background is conveying content or a CSS
icon is highlighting something vis a vis being purely decorative, it
is an informational CSS image that needs role=image and suitable text.
But going back to the F3 issue, the baseline concept considered
during WCAG2 development is relevant. The author relied on CSS as a
baseline. Now the concept is replaced with CR-4 i.e. "accessibility
support". This applies to every SC. SC 1.1.1 too needs to be met using
in accessibility supported way. This includes conveying info and
ensuring the same functionality. So this already is covered by WCAG2
today and does not require any more work in the guidelines moving
forward IMO.
Regards,
Sailesh

On 1/5/16, Andrew Kirkpatrick notifications@github.com wrote:

(adding my comments from the survey)
This failure was quite simple initially in that it focused on the fact that
there is no way to programmatically associate a text alternative with a CSS
background image, and was therefore a clear SC 1.1.1 failure if the image
was content-bearing. (it is a little dicey when dealing with an image with
content but for which the content is repeated in an accessible way on the
same page)

I'm inclined to agree that a 1.1.1 failure isn't created when the visual
image isn't displayed as a result of CSS being turned off. I do definitely
agree that this is a problem for users, but don't think that we can add this
to 1.1.1.

I hate to suggest that this might be part of 1.3.1, but it is an
uncomfortable fit anywhere so we need to make sure that this is clearer
moving forward if we can't resolve where this fits within WCAG 2.0.

---

Reply to this email directly or view it on GitHub:
#80 (comment)

Updated proposal for Issue 80:

1. Changes to F3: https://github.com/w3c/wcag/pull/120/files#diff-e53b5d341a0bd99fdf2208e9ab7c9475
2. Create a new (and separate) technique that addresses the "images not visible when high contrast mode is on" concern.

Ø Updated proposal for Issue 80:

My preference is that we would not modify F3 until we had the new technique ready to go. Also in check #2 the term assistive technology could be taken broadly to include accessibility features that turn off CSS background images.

Jonathan

This won't be published until September 2016, so that should be plenty of time for someone to write it.

There is concern here amongst the working group about the use of the term AT here.

Also is this a failure for people who are NOT using AT?

We are going to leave this open. It would be good to have a new technique for dealing with disappearing background images in high colour contrast mode.

ACTION-318 - Horton to look at new technique for disappearing background images. [on Sarah Horton - http://www.w3.org/WAI/GL/track/actions/318].

I also think we should look at creating a technique for better CSS background images and ARIA or other text alternatives. Not to codify bad practice but to acknowledge what devs are doing in the real world - a la Sprites etc.

@sarah-horton Any progress/update on your new technique for disappearing background images? Thanks http://www.w3.org/WAI/GL/track/actions/318

I could write up a technique for role=img with alt / aria-label when
CSS background image is used if the group sees merit in this. But does
it have to be linked to the high/low contrast technique?
Thanks,
Sailesh

On 2/5/16, joshueoconnor notifications@github.com wrote:

@sarah-horton Any progress/update on your new technique for disappearing
background images? Thanks http://www.w3.org/WAI/GL/track/actions/318

---

Reply to this email directly or view it on GitHub:
#80 (comment)

@spanchang That would be great. Tbh, I don't think this technique can be done is isolation from the issue but I would really like to see what you come up with regarding making background images accessible using role=img and ARIA label mechanisms. Do please link in with @sarah-horton on this - you could collaborate?

Sarah,
Here is a draft of what I had in mind with examples.

https://www.w3.org/WAI/GL/wiki/ARIATechnique_usingImgRole_with_aria-label_forCSS-backgroundImage

Title: Using role=img and aria-label to render informational non-text
content via CSS
Alternative: Title: Rendering images as background via CSS, when
native image element cannot be used

Application:
SC 1.1.1 Level A)
Note:
SC 2.4.4 may apply to links with CSS background images that convey info
SC 1.4.5 may apply to images of text used as background

Description:
The objective of this technique is to demonstrate how WAI-ARIA
role=img and the aria-label property may be employed to render
informational non-text content in the background via CSS when
design or implementation challenges constrain the ability to use
native elements like the HTML IMG element instead.

An element that is styled with the background image is exposed much
like a native HTML IMG element by screen reader software when the
element is assigned a role="img" and equivalend text with the
aria-label attribute.

However, when users alter viewing preferences by suppressing author
supplied styles or by using platform / user agent features, it is
possible that the background image is not rendered or fails to convey
the intended information. (See Failure F3).

Content authors and developers are therefore advised to use
background images to render information only when native elements
cannot be used.

Examples:
Informational image in the background
Image of text in the background
Links with logo images in the background

Live example:
http://mars.dequecloud.com/demo/ImgRole.htm
Related Techniques
F3: Failure of Success Criterion 1.1.1 due to using CSS to include
images that convey important information

Test Procedure:

1. Check if the background image conveys essential information that:

• helps to better understand content on the page, or
• is required to understand the purpose or state of a user interface
  element on the page
• Check if the element that is styled with the background image has
  role="img" and a non-empty meaningful aria-label value

Expected Outcome:
Both tests 1 and 2 are true

Thanks,
Sailesh Panchang

On 2/12/16, Sailesh Panchang sailesh.panchang@deque.com wrote:

Hello Sarah,
Please can you take a look at the 3 examples of CSS images on this
page. Will this be something you can work with for Issue#318?
http://mars.dequecloud.com/demo/ImgRole.htm
I have applied role=img and aria-label to these background images and
hope they are being rendered alright.
They are read by JAWS, NVDA and VO on iOS and OSX.
I will write up a technique for WG review.
Thanks,
Sailesh

On 2/5/16, Sarah Horton notifications@github.com wrote:

@spanchang sounds like a great plan!

---

Reply to this email directly or view it on GitHub:
#80 (comment)

@spanchang and I discussed the following proposed technique for making CSS-based images accessible to assistive technologies, and whether this technique should be combined with a technique for making CSS-based images accessible when background images do not display, such as in high contrast mode:

https://www.w3.org/WAI/GL/wiki/ARIATechnique_usingImgRole_with_aria-label_forCSS-backgroundImage

We decided that they should be different techniques. The technique for CSS images and AT is straightforward but does not address high contrast mode. The technique for high-contrast mode is more complex and involves use of a script, but does provide a solution to CSS images and AT, as well as high contrast mode. We propose to provide both techniques, with cross references.

Sorry to pick this up more than 2 years after I initiated this discussion. This thread has spawned a draft for a role=image technique which is not yet published (if it ever will).

I think what needs to change is either the association of F3 with 1.1.1, or a change along the lines of the (now closed) pull request #120 proposed by Andrew at the time, which clarifies that the topic here is programmatic availability of the information of the image, not that information "is also available when the CSS image is not displayed" (because that can mean: visually available, which would not be a topic for 1.1.1).

Andrew's suggestion was then to think about a new technique that addresses the "images not visible when high contrast mode is on" concern. I believe this has not happened (correct?), but the fact that this aspect is not yet covered elsewhere does not justify keeping the ambiguity about the visual aspect in a Failure F3, which only references 1.1.1.

Can we return to pull request #120 and get F3 modified?

I personally take the stance that non-decorative content that is indicated through techniques meant for decorative content must be visible when decorative images are removed such as in high contrast mode. While adding text using another method may be programmatically determinable -- if it's not shown in high contrast mode then it's not accessibility supported. Just like if you used display:none it wouldn't be accessibility supported to a screen reader.

The new technique is "Setting role of img on icon fonts" #531 .

I agree with @mraccess77's comments that this is an issue and that it seems to be closest to being a conformance issue. The problem is that it doesn't align with any existing SCs.
@awkawk AWK's previous suggestion that this could be 1.3.1 makes sense for situations where the background image persists. (We also agree that it's pretty tough to argue that F3 is actually a failure of 1.1.1.) It's even possible that if background images properly met 1.3.1 that would 'solve' this issue (or at least get us in situation where requiring ALT text to appear when the image cannot be displayed-- or the user chooses NOT to display images -- would resolve the problem.) But where something entirely disappears from the presentation due to high contrast mode, it seems difficult to me to say that a missing icon (i.e., something no longer being presented) can still apply as a failure of an SC entirely concerned with offering equivalent facilitation to something that is in the presentation.

Mary Jo and Erich Manser are going to be discussing this at CSUN this week. We feel like we need clarity on the following:

• how does one indicate a failure to meet a conformance requirement if the symptom doesn't align with any of the SCs?
• what exactly is technically happening in Windows High Contrast mode? Can we leverage that into a new SC that covers not just HC but CSS-type failures?
• has there been any consideration to including an equivalent to the Revised 508 5.3 and/or 5.2.2 -- essentially saying that authors need to support user preferences AND not interfere with accessibility features of the user agent/os?

We're hoping the LVTF will produce an SC that allows HC issues to be properly caught in 2.2 OR comes back with some kind of defensible rationale for where and how they can be captured (and the failure defended) in 2.1.

I think two things have changed now:

1. We have a technique (ARIA24) for identifying images, which helps in the scenario of a user-agent removing images. That's attached to SC 1.3.1.
2. Windows HCM doesn't automatically remove background images any more (as of Window 10 I think?), it applies a background to text over images.

So I think the only thing in F3 that needs changing is to remove the last part of step 3: "...and is also available when the CSS image is not displayed".

I still come across icons used as backgrounds without any hidden text for screenreaders, so I think it's still a valid fail.

I disagree with @alastc about removing step 3. When you say "Windows doesn't remove background images" I think you are really saying Edge doesn't remove background images under Win 10. IE 11 and Firefox still do remove CSS images under high contrast mode. Just because we have an ARIA technique doesn't mean that user agents are supporting it yet.

Hi @mraccess77,

I didn't say remove step 3, it would still read:

If an image does convey important information, the information is provided to assistive technologies.

ARIA24 is a slightly different issue to HCM. Off the top of my head I think the supports/doesn't support list for HCM is something like this:

Removes background images in HCM:

• Windows 7 & 10 - IE, Firefox

Shows background images in HCM:

• Windows 7 - Chrome
• Windows 10 - Chrome, Edge

(Others like Safari not having a HCM except at a more fundamental graphics level. It's annoying about Firefox, is there a bug for that yet?)

But the point for F3 is: What SC is it failing if the background images are removed but there is alt text?

It is a failure of 1.1.1, and the bit in the description about alternative viewing is in a note: "Embedding information into a background image can also cause problems for people who use alternate backgrounds".

I'm not saying it is not an issue, but it is at least dependant on accessibility support, and there are better options on the user-agent side (e.g. chrome's pluggin).

@alastc Chrome's plug-in is not that good as it applies a filter to the page which often makes text harder to see and causes lower contrast on many pages when used with the increase contrast feature. The invert color features inverts background images -- inverted images are harder to read and interpret. I personally believe that background images should only be used for decorative content and thus should be safe to assume they can be removed. The fact that Firefox and IE remove them is the correct behavior -- that is how it should work -- it is not a bug.

@alastc -- regarding ARIA 24 -- that technique is very much scoped to spans for icons because we can't apply role of img to containers that contain other content as images can't have child content. Also once we had role of img screen readers should ignore text inside of the container.

I personally believe that background images should only be used for decorative content and thus should be safe to assume they can be removed. The fact that Firefox and IE remove them is the correct behavior -- that is how it should work -- it is not a bug.

I appreciate that, but my impression is that there are certain approaches people use such as (in old fashioned terms) 'sprite sheets', icons within nav bars / toolbars, and certain banner scenarios where using a background is the default choice in development.

Requiring that all non-decorative images are foreground images would be like standing in the way of an incoming tide, it isn't going to work. I think (but don't know for sure) that is why IE/Edge has changed it's behaviour. To make progress we'll need to figure out what to ask of the user-agents, and what to ask of authors, in a way that will work.

But getting back to the topic of the issue:

But the point for F3 is: What SC is it failing if the background images are removed but there is alt text?

Inline CSS sprite maps have been around for a long time -- so there have long been techniques to provide the same result and speed benefits. What SC is it failing? Well it's failing people with low vision who can't see text that is provided with aria-label or CSS off-screen techniques. The fact that alt text in general is not made available to people by browsers is an abilistic point of view. The assumption is that if you can see you can see the image clear and interpret what it is and the image doesn't get in the way. If not then you must be blind and using a screen reader. People don't consider the millions of people in the middle who need the alternative text but do have some vision and may want the image removed or want the image but need help interpreting the image.

I'm not going to block this -- but I will say it's a huge departure from how this group has historically treated it and testing methodologies will need to be updated as this impacts regulations that include WCAG such as Section 508 revised.

Hi Alastair and all,

You wrote:

Requiring that all non-decorative images are foreground images would be like standing in the way of an incoming tide

Then again, some see the CSS background-image property as an anti-pattern and time to leave it behind.

Laura

Jon, I'm not saying it is a non-issue, I'm making a very similar point to Andrew and you from Jan 2016, above: #80 (comment) which is why I don't understand why it is such a change?

Since then we've added a technique that applies to a sub-set of the possible issues that goes under 1.3.1.

Another change is that, after 10 years of a static set of guidelines, we're making noramtive changes (relatively) regularly. When we're adding or updating guidelines we have to look at exactly how each current one in applied. It appears that the technique slightly over-reached (which is fine for a sufficient technique, not for a failure technique).

The update provided above also removed that aspect of step 3, it isn't a new point (I probably should have read more of the content above!).

The user-agent support is currently a mess, the 'anti-pattern' of background images is wide spread, it isn't covered by 1.1.1. It isn't a clear situation.

I agree it's an issue, but let's find a way of addressing it properly, like the discussion in #623 (thanks for the reminder Laura).

F24 also says this "Note 2: Background color may also be specified using a background image with the CSS property 'background-image' or with the CSS property 'background' (with the URI of the image, e.g., 'background: url("images/bg.gif")'). With background images, it is still necessary to specify a background color, because users may have images turned off in their browser. But the background image and the background color need to be checked."

Hi, brining this up again - it seems like the second part of step 3 is not a fail of WCAG 1.1.1 and this technique should have test 3 updated to remove the available when CSS is disabled part as CSS is a technology that can be relied upon to meet WCAG. Do folks agree with that change:

Change: If an image does convey important information, the information is provided to assistive technologies and is also available when the CSS image is not displayed.

To: If an image does convey important information, the information is provided as a text that is programmatically associated

If an image does convey important information, the information is provided as a text that is programmatically associated

I could get behind this, yes

@mraccess77 -- If an image does convey important information, the information is provided as a text that is programmatically associated with what ???

Could be:

If an image does convey important information, the information is provided as a text that is available programmatically.

If an image does convey important information, the information is provided as a text that is available to assistive technology.

Where does the "important" in "important information" actually come from? Nowhere in SC 1.1.1 does it say that only important non-text content needs a text alternative, but all of them, unless they are purely decorative. There is also no other technique in SC 1.1.1 that limits applicability to important information - except for F3 in conjunction with the CSS graphics. I would plead for removing the "importent" in F3 in the heading and in the text

That's a good point. I feel like information (no qualifier) is too broad. We could borrow from pure decoration so then step three could be:

If an image is serving more than an aesthetic purpose, then text which is available to assistive technology describes that purpose.

@bruce-usab My use of "programmatically associated" comes from the definition of text alternative. WCAG requires that all text alternatives be programmatically determinable or programmatically associated. In this case what I think it would mean is the alternative would have to be in the same relative order as the image or somehow referenced in text to ensure any meaning communicated by visual relationship is there - as I understand it that's also why programmatically associated was put into the definition of text alternative. In regards to the word "important" I'd be fine changing that to match the language used elsewhere such as "non-decorative" or whatever is needed.

I am thinking of situations where the background image conveys important information that is not otherwise conveyed. With word processing, this can manifest as a watermark that has says DRAFT or DO NOT SHARE. The same thing can happen with HTML and background images. With CSS, there is not anything for the programmatically determinable text to be programmatically associated with. I think that dilemma informed the current phrasing in Step 3.

Perhaps, but what's I'm suggesting is that the location of the text alternative may matter and impact meaning. I suppose it could be caught under SC 1.3.2 or 1.3.1, etc. The intent of programmatically associated was to ensure that if the image alt text did not provide everything the person could know where to look to find the alternative. CSS background images are widely used for informative graphics and while off-screen CSS text is used - others just say well the same information is generally conveyed in the page text as a whole so it's already provided. That may not be an equivalent experience though as if you see the image you get the immediate meaning while if you are a screen reader user you have to read the entire page to figure out that same information or go look for the the text which is not inline where it was needed but rather elsewhere on the page away from it's context. Context is important.

Closing this as inactive. If this does need re-opening, please do so.