Accessibility-insights-web: Guidance suggests CSS pseudo-elements with visually-hidden alternative text might be failures

[mmafe]

Describe the bug

I'm checking a meaningful button that (a) uses pseudo-elements (:before or :after) for its icon and (b) has visually-hidden text indicating the button alternative text.

HTML is as follows:

<button>
  <span class="pseudo-icon" aria-hidden="true"></span>
  <span class="sr-only">Button action!</span>
</button>

CSS is as follows:

.pseudo-icon::before {
    font-family: "Font Awesome 5 Free";
    font-weight: 900;
    content: "\f061";
}

.sr-only {
    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0,0,0,0);
    border: 0;
}

If I run a full assessment on this button, under Semantics / CSS content, the guidance states:

The visual helper for this requirement highlights content inserted in the page using CSS :before or :after.
1. In the target page, examine each highlighted item to verify that it is decorative. An element is decorative if it could be removed from the page with no impact on meaning or function.
2. Record your results:
   - If you find any failures, select Fail, then add them as failure instances.
   - Otherwise, select Pass.

Based on this guidance, if I didn't know HTML very well, I would assume that because the icon is meaningful, this immediately results in a failure.

However, I believe this would be a pass if the meaningful information is provided to assistive tech and is also available when CSS is turned off (see technique F87 for reference).

(Note: I understand there are better ways to code this button, but I'm just trying to establish if this is a false positive.)

To Reproduce
Steps to reproduce the behavior:

1. Go to this codepen
2. Run an assessment
3. Go to the Semantics / CSS content section
4. Turn on the visual helper

Expected behavior

I would expect users to be prompted to do an additional check if they see highlighted items that are meaningful.

Is it possible to add an additional check to this section where users are prompted, specifically in the case of meaningful highlighted items, to turn off CSS styles and verify that the meaningful information is available with CSS turned off?

Are you willing to submit a PR?

Not sure how, but willing to try if necessary.

Did you search for similar existing issues?

Did you search for similar issues in our github issues or on stackoverflow: Yes

[ferBonnin]

@iamrafan @LiLoDavis could you please take a look at this?

Based on the test procedure of F87:
If the inserted content is not decorative, check that the information is provided to assistive technologies and is also available when CSS is turned off.

I am unsure if this implementation covers all possible ATs or someone simply turning off CSS

[msft-github-bot]

This issue has been marked as requiring additional investigation by the Accessibility Insights team. When the issue is ready to be triaged again, please update the issue with the investigation result and add "status: ready for triage". Thank you for contributing to Accessibility Insights!

[LiLoDavis]

@imrafan @ferBonnin When I wrote the procedure, I deliberately simplified it. I didn't include viewing with CSS off in part because it tends to turn pages into gibberish that's difficult to evaluate, and also because I'm not clear what insight is gained, or how it would help eliminate false positives. We already know that the before/after content will disappear. Is it likely that some information that's visually hidden using CSS might become visible when CSS is turned off?

And in any case, you'd still need to determine whether the information is available to ATs. I wish we could simply display the elements with before/after content and their accessible names, but I don't think we'd know for sure what portion of the DOM to include. In your example, the before content is in a span, but it's used to label the button that contains it. So I guess we'd ask users to use the Chrome accessibility tree to determine whether the info is available to ATs?

[ferBonnin]

I understand the simplification and makes sense to me. One option could be to add a note but I +1 your question:

We already know that the before/after content will disappear. Is it likely that some information that's visually hidden using CSS might become visible when CSS is turned off?

@iamrafan thoughts on this?

[ferBonnin]

hey @mmafe from a conversation with @iamrafan
if you consider this from F87: “check that the information is provided to assistive technologies and is also available when CSS is turned off.” As:

1. information is provided to assistive technologies
2. information is also available when CSS is turned off

the example provided would be ok for users who use an ATs, but we do not think it will be accessible for other users that turn off CSS for various reasons (and not necessarily use an AT).

[iamrafan]

It would also be related to F1: Failure of Success Criterion 1.3.2 due to changing the meaning of content by positioning information with CSS as the reading order would be impacted in most of the cases

[LiLoDavis]

To ensure against false positives, we'll need to make the following changes to Semantics > CSS content. Note that test steps starting with lower case Roman numerals (i, ii, iii) should be indented relative to test steps starting with lower case letters (a, b). (I couldn't get the formatting to display properly.)

Requirement:

Meaningful content must not be implemented using only CSS :before or :after.

How to test:

The visual helper for this requirement highlights content inserted in the page using CSS :before or :after. This procedure uses the Web Developer browser extension.

1. In the target page, examine each highlighted item to determine whether it is meaningful or decorative.
   a. An element is meaningful if it conveys information that isn't available through other page content.
   b. An element is decorative if it could be removed from the page with no impact on meaning or function.
2. If inserted content is meaningful:
   a. Determine whether the information in inserted content is available to assistive technologies:
   i. Open the Accessibility pane in the browser Developer Tools.
   ii. In the accessibility tree, examine the element with inserted content and its ancestors.
   iii. Verify that any information conveyed by the inserted content is shown in the accessibility tree.
   b. Determine whether the information in inserted content is visible when CSS is turned off:
   i. Use the Web Developer browser extension (CSS > Disable All Styles) to turn off CSS.
   ii. Verify that any information conveyed by the inserted content is visible in the target page.
3. Record your results:
   a. If you find any failures, select Fail, then add them as failure instances.
   b. Otherwise, select Pass.

How to fix:

• Good: Ensure that any information in inserted content is (1) available to assistive technologies, and (2) visible when CSS is turned off.
• Better: Avoid inserting meaningful page content using CSS :before or :after.

[msft-github-bot]

This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!

[ferBonnin]

just as a summary to whomever picks this up, it is text changes in our test.

[karanbirsingh]

@ferBonnin the semantic content changes have been merged & should be in canary

[ferBonnin]

Hey @mmafe we have made changes to our Semantics test guidance. This should be now in the production extension.

[mmafe]

I just saw this while checking a page - so happy to see it in production. Thank you!