WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: when is a list not a list?

for

From: Niranjan Vala
Date: Feb 27, 2022 1:49AM

Hi Glen, Have just read all of your replies. So you have tested this with
Firefox as well and all possible screen reader and browser combinations.
Yah I can understand your curiosity in trying to understand why ATs are
behaving like this even AOM is exposing all the required accessibility
information to the AT. But this is not something in our hands so the only
thing left for us is to find some workaround for this kind of rare problem.
It's not about the gist of your original question, We all were trying to
find a solution for this kind of problem. It seems that you are working to
solve this accessibility problem.



Regarding content inserted by css content property, Yes you are absolutely
right that the content is computed in the accessible name computation and
thus exposed to the ATs. JAWS is smart enough to ignore the text in cases
like this. What I suggest to you is that if possible, use empty alt
property after css content property as described below.



element::after {

content: “Whatever the content is” / “”; // Empty alt after the slash ‘/'

}



I have just tested this with NVDA and it is behaving as expected.

On Sun, 27 Feb 2022 at 00:17, glen walker < <EMAIL REMOVED> > wrote:

> Ok, perhaps my last comment on this topic. Regarding the CSS content
> property, I forgot to say that I had tested it without an aria-label so
> that step 2C in the accessible name calculation would be irrelevant and
> thus 2F *might* apply, but 2F conditions the use of CSS content by saying
> if the "role allows name from content", then CSS content should be
> applied. A list (ul) is not considered an element that gets its name from
> content (https://www.w3.org/TR/wai-aria/#namefromcontent) so CSS content
> should be ignored and JAWS is correct.
>
> On Sat, Feb 26, 2022 at 11:27 AM glen walker < <EMAIL REMOVED> >
> wrote:
>
> > Yes, Firefox and Chrome. Chrome's AOM inspector is easier to read (for
> > me) than Firefox's, but I had tried both. Both show a valid accessible
> > name and role.
> >
> > I had tried various workarounds (which wasn't the gist of my original
> > question) on Firefox, Chrome, and Safari (iOS) with NVDA, JAWS, and
> > VoiceOver.
> >
> > One side note that I didn't include originally because I was trying to
> > keep my example simple, was that the main list (either <ul> or <div
> > role="list">) also had a CSS content attribute that added text to the
> list
> > (not the listitem). The text was read by NVDA and VoiceOver but not by
> > JAWS. The accessible name calculation says that CSS content should be
> > included in the accessible name, but it's in step 2F which is after step
> 2C
> > so in theory should be ignored if there's an aria-label.
> >
> > On Sat, Feb 26, 2022 at 10:50 AM Niranjan Vala < <EMAIL REMOVED> >
> > wrote:
> >
> >> Have you tried this on firefox? firefox has the accessibility
> >> inspector built-in. I will try it tomorrow because I am currently not on
> >> my
> >> desktop.
> >>
> >>
> > > > >


--
Cheers,

Niranjan G Vala