Clarify the meaning of "is also available" in step #3 of F3 test

[awkawk]

Name: Detlev Fischer Affiliation: 3needs Document: TD Item Number: F3 Part of Item: Tests Comment Type: technical Comment (Including rationale for any proposed change): The third step in the test of F3 says "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". Since assistive technologies are mentioned immediately before the bit "is also available", it is no unambiguously clear that the intent here is to require also the visible presence of replaced text when content is viewed with CSS disabled (i.e. in cases where background images disappear and some suitable alternative text that is off-screen-positioned when CSS is active is shown instead). An additional suggestion: The use of CSS background images for controls is now very frequent, so I wonder whether a sufficient technique describing replaced text (off-screen positioned when CSS is active, replacing the image when CSS is off) would be a good idea. Such a technique currently does not exist, I bevieve. Should I draft something?

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

[awkawk]

Jon Avila will investigate.

[mraccess77]

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".

[mraccess77]

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.

[awkawk]

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

[awkawk]

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

[spanchang]

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?

[awkawk]

(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.

[mraccess77]

Ø 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

[spanchang]

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/w3c/wcag/issues/80#issuecomment-169016194.

---

Reply to this email directly or view it on GitHub: https://github.com/w3c/wcag/issues/80#issuecomment-169032047

[mraccess77]

Ø >>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

[spanchang]

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: https://github.com/w3c/wcag/issues/80#issuecomment-169024548

[awkawk]

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.

[mraccess77]

Ø 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

[awkawk]

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

[joshueoconnor]

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

[joshueoconnor]

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

[joshueoconnor]

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.

[joshueoconnor]

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

[joshueoconnor]

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.

[joshueoconnor]

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

[spanchang]

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: https://github.com/w3c/wcag/issues/80#issuecomment-180373580

[joshueoconnor]

@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-horton]

@joshueoconnor I have not made progress on this yet, sorry. @spanchang maybe you and I could work together on this?

[spanchang]

Hi Sarah, Sure I will love to work with you. I can write up something on use of role=img and AT support. Maybe if you draft something on ACTION-318: for disappearing background images, then we can see how to merge them / get them in sync etc. Also feel free to reach me on 571-344-1765 or spanchang02@yahoo.com. I am in VA. Thanks Josh and Sarah. Sailesh

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

@joshueoconnor I have not made progress on this yet, sorry. @spanchang maybe you and I could work together on this?

---

Reply to this email directly or view it on GitHub: https://github.com/w3c/wcag/issues/80#issuecomment-180439019

[joshueoconnor]

That's great @spanchang and @sarah-horton!

[sarah-horton]

@spanchang sounds like a great plan!

[spanchang]

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: https://github.com/w3c/wcag/issues/80#issuecomment-180479675

[spanchang]

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: https://github.com/w3c/wcag/issues/80#issuecomment-180479675

[sarah-horton]

@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.

[detlevhfischer]

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?

[mraccess77]

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.

[lauracarlson]

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

[mbgower]

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.

[alastc]

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.

[mraccess77]

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.

[alastc]

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).

[mraccess77]

@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.

[mraccess77]

@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.

[alastc]

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?

[mraccess77]

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.

[lauracarlson]

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

[alastc]

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: https://github.com/w3c/wcag/issues/80#issuecomment-169024548 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).

[mraccess77]

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."

[mraccess77]

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

[patrickhlauke]

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

I could get behind this, yes

[bruce-usab]

@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.

[JAWS-test]

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

[bruce-usab]

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.

[mraccess77]

@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.

[bruce-usab]

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.