Consider ignoring pseudo element content for accname if it has explicitly empty alt text

[sivakusayan]

In step 2F.ii, it says that browsers should:

Check for CSS generated textual content associated with the current node and include it in the accumulated text. The CSS :before and :after pseudo elements [CSS2] can provide textual content for elements that have a content model.

• For :before pseudo elements, User agents MUST prepend CSS textual content, without a space, to the textual content of the current node.
• For :after pseudo elements, User agents MUST append CSS textual content, without a space, to the textual content of the current node.

However, we also have the option of setting alt text for the CSS content. Maybe I'm misunderstanding something, but I think it would be nice if CSS content with empty alt text was ignored altogether when computing the accessible name.

[scottaohara]

this is interesting...

i had never even thought to try adding content alt text to a content string that wasn't either a url or a unicode character.

but if one were to do:

div::after {
 content: "visible text"  / "alt text";
}

then "alt text" would become the exposed content in the a11y tree, while "visible text" would remain rendered on the page. that seems, odd and prone to abuse.

[sivakusayan]

Yeah 🙁 I guess I could also see people doing things like:

div::after {
 content: ""  / "screen reader only text";
}

I still think it could potentially be useful to mark certain characters as presentational. For example, if someone wanted to add a hashtag next to headings in a blog (as an additional visual cue for heading permalinks) they could do something like:

<h2 id="some-heading">
  <a href="#some-heading">
    Some heading
  </a>
</h2>

then in the CSS:

h2::before {
  content: "#" / "";
}

Would it make sense to only respect the alt text if the alt text is explicitly empty? That would make it so pseudo element content inclusion is similar to what's done in step 2A where hidden nodes are ignored.

[cookiecrook]

I put in some WPT placeholders for these tests in:
web-platform-tests/interop-accessibility#36

and I'm very familiar with the decade of history of alternative text for CSS generated content with -webkit-alt:, alt:, and later this newer syntax adopted by Elika to better support the cascade. Looking forward to discussing.

[spectranaut]

@cyns volunteered to write tests! :) cyns when you assign yourself to the test issue you can unassign yourself here

[cookiecrook]

I agree that

content: "foo" / "";

Is effectively equivalent to alt="" and "foo" should therefore be ignored in the accname comp.

But I want to make sure we're not suggesting emptying the pseudo-element alternative when the optional alt fallback is not specified, like this:

content: "foo";

the pseudo element's label here should remain "foo" not "".

[cookiecrook]

@cyns volunteered to write tests! :) cyns when you assign yourself to the test issue you can unassign yourself here

Here's the issue, but I don't think @cyns is assignable... Did you check your team invitation?
web-platform-tests/interop-accessibility#36

[sivakusayan]

@cookiecrook

But I want to make sure we're not suggesting emptying the pseudo-element alternative when the optional alt fallback is not specified.

Yeah, that was what I meant to say. I'll change the title to mention "explicitly empty alt text" rather than just "empty alt text" to make it more clear.

[spectranaut]

@cookiecrook this still has f2fcandidate on it, is there more on this to discuss at TPAC in sept?

[cookiecrook]

Sorry I forgot about this one, but I have started writing the tests in:

• AccName: Name From Contents Tests web-platform-tests/wpt#42354

I'd suggest this issue is overcome by the first one of these new issues?

• AccName term "CSS textual content" for pseudo elements is undefined/ambiguous #204
• AccName algo probably needs an update for ::marker #203

[sivakusayan]

I agree, let's close this in favor of the more general issue 🙂