WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: when is a list not a list?

for

From: Batusic, Mario
Date: Feb 28, 2022 2:07AM

Hi All,

Think a case, that somebody wishes to use SCC classes to depict some content for lsit items. That would be naturally not perceivable for screen readers and using aria-label on list items would be the right way to communicate the content to the AT. So ignoring the right defined ARIA semantics of aria-label attributes would render the correct coded list inaccessible.

Ciao Mario

-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum < <EMAIL REMOVED> > Im Auftrag von Niranjan Vala
Gesendet: Sonntag, 27. Februar 2022 09:49
An: WebAIM Discussion List < <EMAIL REMOVED> >
Betreff: Re: [WebAIM] when is a list not a list?

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.
> >>
> >>
> > > archives at http://webaim.org/discussion/archives
> >


--
Cheers,

Niranjan G Vala