WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Fourth rule of aria > aria-hidden

for

From: Jeremy Echols
Date: Jan 23, 2018 1:43PM

Vimium, a keyboard plugin for Firefox, offers keyboard-accessible tooltips for clickable elements on a given page. Usually it works well, because the tooltips are rarely more than three characters. But on some "busy" sites, where there are a lot of icon-only buttons smashed together, the tooltips can end up overlaying each other and making it very difficult to discern which keystrokes go with which control.

With a tooltip showing the entire accessible label, I could see this being a very difficult UI to implement in a way that doesn't just make the situation worse. Now add in the fact that in many cases the user won't even know they need the overlay until they've navigated to the wrong location. Don't get me wrong, a feature like this would probably be helpful more often than not, but it's definitely a non-trivial problem to solve.

I feel that web developers need to be made aware of the problems they create, rather than expecting (or hoping) assistive technology finds clever ways to get past poor design.

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Tim Harshbarger
Sent: Tuesday, January 23, 2018 11:44 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Fourth rule of aria > aria-hidden

True, but if you could toggle the tooltips on and off with a voice command, it at least would be an improvement over the current situation--until someone could come up with something better.



-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Steve Green
Sent: Tuesday, January 23, 2018 12:37 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Fourth rule of aria > aria-hidden

I agree in principle, but do you have any view on how Dragon might expose the accessible names of all the elements that do not have visible labels? There could be a voice command that displays them all as tooltips, but they would then overlay other content. I can't immediately think of a good solution for this.

Steve

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Birkir R. Gunnarsson
Sent: 23 January 2018 18:22
To: Beranek, Nicholas < <EMAIL REMOVED> >; WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Fourth rule of aria > aria-hidden

In my opinion, It is Dragon's responsibility to expose the accessible name of an element, if different from its visible label, just like a screen reader does.
Dragon has the same access to the accessible name of the element through the accessibility tree as a screen reader.

The proposed WCAG 2.1 success criterion does not address the most common situation, where controls have no visible text label at all but are identified with icons.

I filed an issue against this success criterion on the WCAG GitHub page.

I really like the idea of better supporting speech recognition users, but I also think that the software vendors have the responsibility to use available technologies and content and translate that information to the optimal end user experience.
We can't lay all the responsibility of that on the webpage author if the software can do it.




On 1/23/18, Beranek, Nicholas via WebAIM-Forum < <EMAIL REMOVED> > wrote:
> I would not call that an issue with Dragon. Dragon is going by the
> accessible name and, naturally, aria-label will take precedence in
> most cases to provide it. When we declare issues, we make sure to
> mention that ARIA is not just about screen readers, but rather all
> assistive technologies that use the accessibility API, at least to
> some degree, including dictation programs such as Dragon.
>
> Dragon 13 started supporting ARIA in 2014. My understanding is that
> they support only what they need to, such as aria-labelledby,
> aria-label, ARIA roles such as "button", "link", "checkbox", and
> "radio". It doesn't appear to be impacted by ARIA properties such as
> aria-hidden. For example, I was able to perform a simple "click link"
> command on an element that I set to aria-hidden="true".
>
> We held a team discussion regarding the latest changes to WCAG 2.1 as
> we prepare for its official REC status hopefully in June. This reminds
> me of one of the new success criteria: SC 2.4.12 Label in Name
> (formerly Accessible Name). It states that the visible label must
> match the programmatic label. It benefits users with speech
> recognition programs since the aria-label and aria-labelledby
> attributes are supported and take precedence. This is already a best
> practice in our handbook, but it will be great to enforce it under a success criterion.
>
> Nick Beranek
> Capital One
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Mallory
> Sent: Tuesday, January 23, 2018 3:55 AM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Fourth rule of aria > aria-hidden
>
> I believe so. The biggest issues with Dragon is that
> naturally-invisible aria-labels can be triggered by it, as well as the
> fact that an icon doesn't tell you the name of a button (is it "plus"?
> "Zoom in"? "increase"?)
>
> I can test with 13 to be certain.
>
> cheers,
> Mallory
>
> On Tue, Jan 23, 2018, at 8:57 AM, Gijs Veyfeyken wrote:
>> How's the support for ARIA among speech recognition software like
>> Dragon Naturally Speaking these days?
>> For example, if you "hide" a map component with aria-hidden, it will
>> no longer be possible to use speech commands to control the map (pan
>> and zoom buttons)?
>>
>> Kind regards,
>>
>> Gijs
>>
>> ---
>> Gijs Veyfeyken
>> AnySurfer - towards an accessible internet http://www.anysurfer.be/en
>> <http://www.anysurfer.be/en>; Brussels - Belgium
>>
>>
> >
> The information contained in this e-mail is confidential and/or
> proprietary to Capital One and/or its affiliates and may only be used
> solely in performance of work or services for Capital One. The
> information transmitted herewith is intended only for use by the
> individual or entity to which it is addressed. If the reader of this
> message is not the intended recipient, you are hereby notified that
> any review, retransmission, dissemination, distribution, copying or
> other use of, or taking of any action in reliance upon this
> information is strictly prohibited. If you have received this
> communication in error, please contact the sender and delete the material from your computer.
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.