E-mail List Archives
Thread: Fourth rule of aria > aria-hidden
Number of posts in this thread: 24 (In chronological order)
From: Fernand van Olphen
Date: Mon, Jan 22 2018 2:21AM
Subject: Fourth rule of aria > aria-hidden
No previous message | Next message →
Hi everyone,
According to the fourth rule of ARIA, you shouldn't use aria-hidden="true" on a visible focusable element.
So, this markup is a violation:
<button aria-hidden="true">press me</button>
What about the next markup?
<div aria-hidden="true">
(some other markup ...)
<button>press me</button>
(some other markup ...)
</div>
In this case aria-hidden="true" is used on the container div, and the visible focusable element sits inside it. Is this also a violation of the fourth rule?
Kind regards,
Fernand van Olphen
Accessibility Advisor
Municipality of The Hague,
www.denhaag.nl<;http://www.denhaag.nl>;
De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer
From: Patrick H. Lauke
Date: Mon, Jan 22 2018 2:29AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
On 22/01/2018 09:21, Fernand van Olphen wrote:
> Hi everyone,
>
> According to the fourth rule of ARIA, you shouldn't use aria-hidden="true" on a visible focusable element.
>
> So, this markup is a violation:
>
> <button aria-hidden="true">press me</button>
>
> What about the next markup?
>
> <div aria-hidden="true">
> (some other markup ...)
> <button>press me</button>
> (some other markup ...)
> </div>
>
> In this case aria-hidden="true" is used on the container div, and the visible focusable element sits inside it. Is this also a violation of the fourth rule?
Yes.
The whole point is: if there's something than can receive focus, don't
hide it. It's irrelevant if you apply aria-hidden to the thing, or the
parent/ancestor of the thing.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From:
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
On 22/01/2018 09:21, Fernand van Olphen wrote:
> In this case aria-hidden="true" is used on the container div, and the visible focusable element sits inside it. Is this also a violation of the fourth rule?
It is, but the Using ARIA doc doesn't make this clear. I've filed an
issue there, so hopefully we can get the 4th rule updated.
https://github.com/w3c/using-aria/issues/32
Léonie.
>
>
> Kind regards,
> Fernand van Olphen
> Accessibility Advisor
> Municipality of The Hague,
> www.denhaag.nl<;http://www.denhaag.nl>;
>
> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer
> > > > >
--
@LeonieWatson @ = EMAIL ADDRESS REMOVED = Carpe diem
From: Steve Faulkner
Date: Mon, Jan 22 2018 2:58AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
Have updated the 4th rule, thanks for feedback.
https://w3c.github.io/using-aria/#fourth
--
Regards
SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
On 22 January 2018 at 09:36, Léonie Watson < = EMAIL ADDRESS REMOVED = > wrote:
> On 22/01/2018 09:21, Fernand van Olphen wrote:
>
>> In this case aria-hidden="true" is used on the container div, and the
>> visible focusable element sits inside it. Is this also a violation of the
>> fourth rule?
>>
>
> It is, but the Using ARIA doc doesn't make this clear. I've filed an issue
> there, so hopefully we can get the 4th rule updated.
> https://github.com/w3c/using-aria/issues/32
>
> Léonie.
>
>
>
>>
>> Kind regards,
>> Fernand van Olphen
>> Accessibility Advisor
>> Municipality of The Hague,
>> www.denhaag.nl<;http://www.denhaag.nl>;
>>
>> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u
>> op: http://www.denhaag.nl/disclaimer
>> >> >> >> >>
>>
> --
> @LeonieWatson @ = EMAIL ADDRESS REMOVED = Carpe diem
>
> > > > >
From: Joshue O Connor - InterAccess
Date: Mon, Jan 22 2018 3:05AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
Thats a good catch all :-)
Josh
Steve Faulkner wrote:
> Have updated the 4th rule, thanks for feedback.
>
> https://w3c.github.io/using-aria/#fourth
>
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>
> On 22 January 2018 at 09:36, Léonie Watson< = EMAIL ADDRESS REMOVED = > wrote:
>
>> On 22/01/2018 09:21, Fernand van Olphen wrote:
>>
>>> In this case aria-hidden="true" is used on the container div, and the
>>> visible focusable element sits inside it. Is this also a violation of the
>>> fourth rule?
>>>
>> It is, but the Using ARIA doc doesn't make this clear. I've filed an issue
>> there, so hopefully we can get the 4th rule updated.
>> https://github.com/w3c/using-aria/issues/32
>>
>> Léonie.
>>
>>
>>
>>> Kind regards,
>>> Fernand van Olphen
>>> Accessibility Advisor
>>> Municipality of The Hague,
>>> www.denhaag.nl<;http://www.denhaag.nl>;
>>>
>>> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u
>>> op: http://www.denhaag.nl/disclaimer
>>> >>> >>> >>> >>>
>>>
>> --
>> @LeonieWatson @ = EMAIL ADDRESS REMOVED = Carpe diem
>>
>> >> >> >> >>
> > > > --
Joshue O Connor
Director | InterAccess.ie
From: Birkir R. Gunnarsson
Date: Mon, Jan 22 2018 5:10AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
What about content that cannot be made accessible toa screen reader,
but still has to be oprable with the keyboard?
I am primarily thinking of map components. A keyboard only user needs
to be able to operate the map controls, but to a screen reader the map
clutters up the page. Assuming there is an accessible alterantive to
get text instructions or perform the primary function of the map,,
isn't it valid (though not desireable) use of aria-hidden to hide the
map and its controls from the screen reader user?
On 1/22/18, Joshue O Connor - InterAccess < = EMAIL ADDRESS REMOVED = > wrote:
> Thats a good catch all :-)
>
> Josh
>
> Steve Faulkner wrote:
>> Have updated the 4th rule, thanks for feedback.
>>
>> https://w3c.github.io/using-aria/#fourth
>>
>> --
>>
>> Regards
>>
>> SteveF
>> Current Standards Work @W3C
>> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>>
>> On 22 January 2018 at 09:36, Léonie Watson< = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> On 22/01/2018 09:21, Fernand van Olphen wrote:
>>>
>>>> In this case aria-hidden="true" is used on the container div, and the
>>>> visible focusable element sits inside it. Is this also a violation of
>>>> the
>>>> fourth rule?
>>>>
>>> It is, but the Using ARIA doc doesn't make this clear. I've filed an
>>> issue
>>> there, so hopefully we can get the 4th rule updated.
>>> https://github.com/w3c/using-aria/issues/32
>>>
>>> Léonie.
>>>
>>>
>>>
>>>> Kind regards,
>>>> Fernand van Olphen
>>>> Accessibility Advisor
>>>> Municipality of The Hague,
>>>> www.denhaag.nl<;http://www.denhaag.nl>;
>>>>
>>>> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u
>>>> op: http://www.denhaag.nl/disclaimer
>>>> >>>> >>>> >>>> >>>>
>>>>
>>> --
>>> @LeonieWatson @ = EMAIL ADDRESS REMOVED = Carpe diem
>>>
>>> >>> >>> >>> >>>
>> >> >> >> >
> --
> Joshue O Connor
> Director | InterAccess.ie
> > > > >
--
Work hard. Have fun. Make history.
From: Steve Green
Date: Mon, Jan 22 2018 5:16AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
I agree. We encounter this a lot with third-party plug-ins for maps, interactive charts and all sorts of other features for which accessible alternatives are provided on the same page. These are often keyboard-accessible but not screen reader accessible.
Steve
From: Birkir R. Gunnarsson
Date: Mon, Jan 22 2018 5:21AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
And this is why I have interpreted the 4th rule of ARIA such that
aria-hidden is allowed on elements containing focusable elemnts, while
not allowed on the focusable elements directly.
We all know aria-hidden is dangerous, and warning against frivolous
use is important, bt there, as I see it, legitimate use cases for it,
this being one of them.
On 1/22/18, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
> I agree. We encounter this a lot with third-party plug-ins for maps,
> interactive charts and all sorts of other features for which accessible
> alternatives are provided on the same page. These are often
> keyboard-accessible but not screen reader accessible.
>
> Steve
>
>
From: Patrick H. Lauke
Date: Mon, Jan 22 2018 5:45AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
The rule, in essence, says: you don't want an AT user setting focus to
"nothing", as they're left wondering what they just set focus to. If
it's aria-hidden (or contained inside an aria-hidden container), but
received focus, it's an empty step in the focus cycle.
Nobody dies when this happens, to be clear. And the "rules" of using
ARIA are more good practice maxims, not hard failures.
IF you can justify why something still receives keyboard focus but isn't
announced at all to AT users, cool.
P
On 22/01/2018 12:21, Birkir R. Gunnarsson wrote:
> And this is why I have interpreted the 4th rule of ARIA such that
> aria-hidden is allowed on elements containing focusable elemnts, while
> not allowed on the focusable elements directly.
> We all know aria-hidden is dangerous, and warning against frivolous
> use is important, bt there, as I see it, legitimate use cases for it,
> this being one of them.
>
>
> On 1/22/18, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
>> I agree. We encounter this a lot with third-party plug-ins for maps,
>> interactive charts and all sorts of other features for which accessible
>> alternatives are provided on the same page. These are often
>> keyboard-accessible but not screen reader accessible.
>>
>> Steve
>>
>>
From: Patrick H. Lauke
Date: Mon, Jan 22 2018 5:46AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
On 22/01/2018 12:45, Patrick H. Lauke wrote:
> The rule, in essence, says: you don't want an AT user setting focus to
> "nothing", as they're left wondering what they just set focus to. If
> it's aria-hidden (or contained inside an aria-hidden container), but
> received focus, it's an empty step in the focus cycle.
>
> Nobody dies when this happens, to be clear. And the "rules" of using
> ARIA are more good practice maxims, not hard failures.
>
> IF you can justify why something still receives keyboard focus but isn't
> announced at all to AT users, cool.
At that point, you may even consider adding some SR only text to the
page that explains what's going on, before the user encounters those
"focusable but unannounced" controls, mind.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Steve Faulkner
Date: Mon, Jan 22 2018 6:23AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
In this super simple test case:
https://s.codepen.io/stevef/debug/NXJaGQ
JAWS 2018:
button is navigable via tab key, in case of IE and Chrome, the heading is
announced when the button is focused, in firefox nothing is announced.
NVDA latest:
button is navigable via tab key, in case of IE and Chrome, nothing is
announced when the button is focused, in firefox button name and role is
announced.
--
Regards
SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
On 22 January 2018 at 12:46, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:
> On 22/01/2018 12:45, Patrick H. Lauke wrote:
>
>> The rule, in essence, says: you don't want an AT user setting focus to
>> "nothing", as they're left wondering what they just set focus to. If it's
>> aria-hidden (or contained inside an aria-hidden container), but received
>> focus, it's an empty step in the focus cycle.
>>
>> Nobody dies when this happens, to be clear. And the "rules" of using ARIA
>> are more good practice maxims, not hard failures.
>>
>> IF you can justify why something still receives keyboard focus but isn't
>> announced at all to AT users, cool.
>>
>
> At that point, you may even consider adding some SR only text to the page
> that explains what's going on, before the user encounters those "focusable
> but unannounced" controls, mind.
>
> P
>
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >
From: Fernand van Olphen
Date: Mon, Jan 22 2018 6:57AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
Wordpress suggests to add aria-hidden="true" and tabindex="-1" to visible same-destination-links.
https://make.wordpress.org/accessibility/handbook/best-practices/markup/post-excerpts-for-an-archive-template/#duplicate-links
Fernand
De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer
From: Patrick H. Lauke
Date: Mon, Jan 22 2018 7:02AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
On 22/01/2018 13:57, Fernand van Olphen wrote:
> Wordpress suggests to add aria-hidden="true" and tabindex="-1" to visible same-destination-links.
>
> https://make.wordpress.org/accessibility/handbook/best-practices/markup/post-excerpts-for-an-archive-template/#duplicate-links
Potentially confusing for sighted keyboard users...but not necessarily
outright wrong.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Birkir R. Gunnarsson
Date: Mon, Jan 22 2018 7:07AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
Jaws does not display aria-hidden content in browse mode, but if you
focus it with the keyboard it Is announced. It is very confusing.
I guess there is no one optima solution in this scenari (other than
making those maps accessible of course). :)
On 1/22/18, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 22/01/2018 13:57, Fernand van Olphen wrote:
>> Wordpress suggests to add aria-hidden="true" and tabindex="-1" to visible
>> same-destination-links.
>>
>> https://make.wordpress.org/accessibility/handbook/best-practices/markup/post-excerpts-for-an-archive-template/#duplicate-links
>
> Potentially confusing for sighted keyboard users...but not necessarily
> outright wrong.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >
--
Work hard. Have fun. Make history.
From: Jonathan Avila
Date: Mon, Jan 22 2018 10:46AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
> I am primarily thinking of map components. A keyboard only user needs to be able to operate the map controls, but to a screen reader the map clutters up the page. Assuming there is an accessible alterantive to get text instructions or perform the primary function of the map,, isn't it valid (though not desireable) use of aria-hidden to hide the map and its controls from the screen reader user?
It is my understanding that the specifications indicate that browsers should expose focused aria-hidden content in the accessibility API in order to prevent nothing from being announced by screen readers.
Consider that there may be a number of people with low vision that can benefit from keyboard support and tex-to-speech. Skip links, landmarks, or other techniques can be used to allow screen reader users to skip past if they want. Seems like many screen readers will likely be using the browser cursor anyway and will encounter or pass the information as desired with those navigation commands.
Jonathan
Jonathan Avila
Chief Accessibility Officer
Level Access, inc. (formerly SSB BART Group, inc.)
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)
Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
Looking to boost your accessibility knowledge? Check out our free webinars!
The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.
From: Gijs Veyfeyken
Date: Tue, Jan 23 2018 12:57AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
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
From: Mallory
Date: Tue, Jan 23 2018 1:54AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
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
>
>
> > > >
From: Beranek, Nicholas
Date: Tue, Jan 23 2018 10:53AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
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
From: Birkir R. Gunnarsson
Date: Tue, Jan 23 2018 11:22AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
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 ADDRESS 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
>
>
From: Steve Green
Date: Tue, Jan 23 2018 11:37AM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
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
From: Tim Harshbarger
Date: Tue, Jan 23 2018 12:43PM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
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.
From: Jeremy Echols
Date: Tue, Jan 23 2018 1:43PM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
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.
From: Birkir R. Gunnarsson
Date: Tue, Jan 23 2018 2:28PM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | Next message →
It's always about finding that balance.
I filed an issue against the proposed success criterion specifically
because it does not address the primary problem, that of icon buttons.
In general we encourage authors not to make labels specifically for
accessibility, unless there are strong reasons for doing so (e.g. to
disambiguate otherwise identical controls that user is likely to get
confused about).
But, again, it doesn't address the problem we are talking about here.
If an author creates an icon button and provides an accessible name,
the button is accessible, even with the new success criterion it is
still accessible, but it is not easily usable to a speech recognition
user.
So what success criterion would ensure icon button accessibility for
speech recognition user?
Should WCAG forbid the use of icon buttons without a text label? It
wouldn't be popular, but maybe that's what would have to be done.
Anyways, these are philosophical speculations mostly, goes to show
accessibility is an art and it can be damn complex. I'm just gald I
have access to all the awesome folks that think about the same things
every day, on WebAIM and elsewhere. That is a privellege.
So chers to y'all!
On 1/23/18, Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:
> 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.
>
>
From: Jeremy Echols
Date: Tue, Jan 23 2018 3:25PM
Subject: Re: Fourth rule of aria > aria-hidden
← Previous message | No next message
Yeah, the icon-only situation is very difficult to answer.
I do feel like some stricter requirement for icon-only interactive elements is in order. If they have long-ish accessible labels ("save this user and continue", "cancel editing", "save this user and add another", etc.), tooltips get problematic. Maybe those situations should have a requirement to offer a clear explanation that's visible to all AT, not just screen readers? I have no idea.
I do feel that the topic that needs more attention. Right now I feel like I want to avoid icons entirely, which isn't always an option.