E-mail List Archives
Number of posts in this thread: 3 (In chronological order)
From: konstantin galiakhmetov
Date: Mar 13, 2019 5:20AM
Subject: WCAG and incorrect implementation of keyboard interaction
No previous message | Next message →
hello,
What SC i can mention when i see that a keyboard interaction with a ui
control is implemented in the wrong way.
For example there is a drobdown list and a user has to press tab key to
move to the next item. My user experience says that i must use arrowkey
to choose an option in the drop-down list, not tab key, and i am sure
that this implementation is not correct, but i can not cite aÂ
particular SCÂ because WCAG does not regulate specific implementation.
What should I do in such cases? How can I prove that this implementation
is a major problem? Or I'm wrong and above described behavior is not
critical issue?
--Sincerely, Konstantin.
From: Patrick H. Lauke
Date: Mar 13, 2019 5:35AM
Subject: Re: WCAG and incorrect implementation of keyboard interaction
← Previous message | Next message →
On 13/03/2019 11:20, konstantin galiakhmetov wrote:
> hello,
> What SC i can mention when i see that a keyboard interaction with a ui
> control is implemented in the wrong way.
> For example there is a drobdown list and a user has to press tab key to
> move to the next item. My user experience says that i must use arrowkey
> to choose an option in the drop-down list, not tab key, and i am sure
> that this implementation is not correct, but i can not cite a particular
> SCÂ because WCAG does not regulate specific implementation.
You are correct that you can't normatively fail this particular issue
under any WCAG SC. Even SC 2.1.1 Keyboard only normatively requires that
content be operable with the keyboard, not that it necessarily follow
any specific or appropriate conventions.
> What should
> I do in such cases? How can I prove that this implementation is a major
> problem? Or I'm wrong and above described behavior is not critical issue?
If the authors/developers only care about whether or not it passes WCAG
SCs as the only "proof", then ... there's nothing you can do.
Of course, accessibility (and to a certain extent, usability) goes
beyond the bare minimum baseline of WCAG. Generally, in an audit
situation, I'd mention this sort of mismatch/less than appropriate
keyboard behaviour by saying that yes, while it does pass 2.1.1, it
should really be addressed to match user expectations.
Also, it's not clear from your original message, but: how is this
"dropdown list" exposed programmatically? If it's exposed (and therefore
announced by assistive technologies) as a particular type of widget,
then it should ideally follow that widget's standard behaviour, or AT
users will be even more confused (or, in the worst case, will be unable
to interact with the widget correctly at all, since AT will then assume
only certain keyboard interactions are possible/acceptable on that
particular widget).
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: Mar 13, 2019 8:15AM
Subject: Re: WCAG and incorrect implementation of keyboard interaction
← Previous message | No next message
You can use the keyboard interaction and "developing a keyboard
interface" section of the ARIa Authoring Spec as a reference:
https://www.w3.org/TR/wai-aria-practices-1.1/
This is not normative, meaning you can't cite it as proof that your
dropdown violates WCAG, but it is the most comprehensive keyboard
interaction guidance we have (a bit too comprehensive in some
situations actually).
On 3/13/19, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 13/03/2019 11:20, konstantin galiakhmetov wrote:
>> hello,
>> What SC i can mention when i see that a keyboard interaction with a ui
>> control is implemented in the wrong way.
>> For example there is a drobdown list and a user has to press tab key to
>> move to the next item. My user experience says that i must use arrowkey
>> to choose an option in the drop-down list, not tab key, and i am sure
>> that this implementation is not correct, but i can not cite a particular
>> SCÂ because WCAG does not regulate specific implementation.
>
> You are correct that you can't normatively fail this particular issue
> under any WCAG SC. Even SC 2.1.1 Keyboard only normatively requires that
> content be operable with the keyboard, not that it necessarily follow
> any specific or appropriate conventions.
>
>> What should
>> I do in such cases? How can I prove that this implementation is a major
>> problem? Or I'm wrong and above described behavior is not critical issue?
>
> If the authors/developers only care about whether or not it passes WCAG
> SCs as the only "proof", then ... there's nothing you can do.
>
> Of course, accessibility (and to a certain extent, usability) goes
> beyond the bare minimum baseline of WCAG. Generally, in an audit
> situation, I'd mention this sort of mismatch/less than appropriate
> keyboard behaviour by saying that yes, while it does pass 2.1.1, it
> should really be addressed to match user expectations.
>
> Also, it's not clear from your original message, but: how is this
> "dropdown list" exposed programmatically? If it's exposed (and therefore
> announced by assistive technologies) as a particular type of widget,
> then it should ideally follow that widget's standard behaviour, or AT
> users will be even more confused (or, in the worst case, will be unable
> to interact with the widget correctly at all, since AT will then assume
> only certain keyboard interactions are possible/acceptable on that
> particular widget).
>
> 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.