E-mail List Archives
Thread: Web application - shortcut to manual
Number of posts in this thread: 7 (In chronological order)
From: Miriam Fukushima
Date: Mon, Jul 08 2019 10:43AM
Subject: Web application - shortcut to manual
No previous message | Next message →
Hello everyone,
I am currently developing a web application that allows to edit data of
content objects via large forms.
There is a general button to the manual (an HTML-site), but all elements
in the application are supposed to have a shortcut to the corresponding
paragraph in the manual.
As it currently stands, after about five seconds of inactivity a
popup-button appears at the element currently in focus which links to
the corresponding paragraph.
This button can be clicked and reached via tab. We also thought of
adding options to the user profile where the user can turn these buttons
off or change the interval of inactivity after which the buttons pop up.
The decision for these buttons was based upon the thought that a help
button, icon or link after every form field would be annoying to tab
through as this application will be used by users on a daily basis and a
tool tip would be repetitive and not always explain as well as the manual.
We also thought about adding a short key for keyboard users. But this is
very difficult to get to work with screen readers.
So my questions are, especially regarding screen reader and keyboard users:
1) Would a buttons like these work at all and do they need aria-live=polite?
2) How or where would you expect such a shortcut to the manual? So that
it is usable and unobtrusive for all users alike.
Thank you very much for any suggestions.
Maybe I am overseeing an obvious solution.
Have a nice day everyone!
Miriam
From: glen walker
Date: Tue, Jul 09 2019 1:03AM
Subject: Re: Web application - shortcut to manual
← Previous message | Next message →
F1 has been the classic shortcut key for help for decades. The user can
tab through your form and press F1 on any form elements they need help on
and you can take them to the appropriate paragraph. Just make sure it's
documented which key to use and make sure screen readers know about it too.
On Mon, Jul 8, 2019 at 10:43 AM Miriam Fukushima < = EMAIL ADDRESS REMOVED = >
wrote:
> Hello everyone,
>
>
> I am currently developing a web application that allows to edit data of
> content objects via large forms.
>
> There is a general button to the manual (an HTML-site), but all elements
> in the application are supposed to have a shortcut to the corresponding
> paragraph in the manual.
>
> As it currently stands, after about five seconds of inactivity a
> popup-button appears at the element currently in focus which links to
> the corresponding paragraph.
>
> This button can be clicked and reached via tab. We also thought of
> adding options to the user profile where the user can turn these buttons
> off or change the interval of inactivity after which the buttons pop up.
>
>
> The decision for these buttons was based upon the thought that a help
> button, icon or link after every form field would be annoying to tab
> through as this application will be used by users on a daily basis and a
> tool tip would be repetitive and not always explain as well as the manual.
>
> We also thought about adding a short key for keyboard users. But this is
> very difficult to get to work with screen readers.
>
>
> So my questions are, especially regarding screen reader and keyboard users:
>
> 1) Would a buttons like these work at all and do they need
> aria-live=polite?
>
> 2) How or where would you expect such a shortcut to the manual? So that
> it is usable and unobtrusive for all users alike.
>
>
> Thank you very much for any suggestions.
>
> Maybe I am overseeing an obvious solution.
>
>
> Have a nice day everyone!
>
> Miriam
>
> > > > >
From: Miriam Fukushima
Date: Tue, Jul 09 2019 1:30AM
Subject: Re: Web application - shortcut to manual
← Previous message | Next message →
Thank you very much for the input.
F1 is already the help shortcut key for the browser itself. I am not
sure if we should change that.
And if we provide a shortcut key, we also have to provide the option to
change this to any other key as this is one criteria in the German
equivalent of WCAG.
The customer also wants the visual buttons to appear on the form fields.
They could be hidden from keyboard and screen reader users, but should they?
On 09.07.2019 09:03, glen walker wrote:
> F1 has been the classic shortcut key for help for decades. The user can
> tab through your form and press F1 on any form elements they need help on
> and you can take them to the appropriate paragraph. Just make sure it's
> documented which key to use and make sure screen readers know about it too.
>
>
> On Mon, Jul 8, 2019 at 10:43 AM Miriam Fukushima < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Hello everyone,
>>
>>
>> I am currently developing a web application that allows to edit data of
>> content objects via large forms.
>>
>> There is a general button to the manual (an HTML-site), but all elements
>> in the application are supposed to have a shortcut to the corresponding
>> paragraph in the manual.
>>
>> As it currently stands, after about five seconds of inactivity a
>> popup-button appears at the element currently in focus which links to
>> the corresponding paragraph.
>>
>> This button can be clicked and reached via tab. We also thought of
>> adding options to the user profile where the user can turn these buttons
>> off or change the interval of inactivity after which the buttons pop up.
>>
>>
>> The decision for these buttons was based upon the thought that a help
>> button, icon or link after every form field would be annoying to tab
>> through as this application will be used by users on a daily basis and a
>> tool tip would be repetitive and not always explain as well as the manual.
>>
>> We also thought about adding a short key for keyboard users. But this is
>> very difficult to get to work with screen readers.
>>
>>
>> So my questions are, especially regarding screen reader and keyboard users:
>>
>> 1) Would a buttons like these work at all and do they need
>> aria-live=polite?
>>
>> 2) How or where would you expect such a shortcut to the manual? So that
>> it is usable and unobtrusive for all users alike.
>>
>>
>> Thank you very much for any suggestions.
>>
>> Maybe I am overseeing an obvious solution.
>>
>>
>> Have a nice day everyone!
>>
>> Miriam
>>
>> >> >> >> >>
> > > > --
Mit freundlichen GrüÃen
Miriam Fukushima
- Online Entwicklung -
---------------------------------------------------
GLAMUS
Gesellschaft für moderne Kommunikation mbH
Gartenstr. 24, 53229 Bonn
http://www.glamus.de/ mailto: = EMAIL ADDRESS REMOVED =
Tel: +49 228 97617-75 Fax: +49 228 97617-55
HRB: Bonn 6287
Geschäftsführer: Ulrich Santo - Gerhard Loosch
---------------------------------------------------
From: Patrick H. Lauke
Date: Tue, Jul 09 2019 2:25AM
Subject: Re: Web application - shortcut to manual
← Previous message | Next message →
On 09/07/2019 08:30, Miriam Fukushima wrote:
> And if we provide a shortcut key, we also have to provide the option to
> change this to any other key as this is one criteria in the German
> equivalent of WCAG.
Just on that point, I assume you're referring to
https://testen.bitv-test.de/index.php?a=di&iid=112&s=n which is the BITV
inclusion of WCAG 2.1 2.1.4 Character Key Shortcuts
https://www.w3.org/TR/WCAG21/#character-key-shortcuts
Note that if you were going to go with F1, that key is exempt from the
requirement of 2.1.4, which only relates to printable characters (and
there's text in the BITV test procedure there to clarify that the F1-F12
keys don't fall under the test).
As for "hijacking" the F1 to provide help for the web site/app and
overriding the browser's F1 help, I'd say that's a mild/minor point, and
as long as it's explained to the user, it's acceptable (and they can
still trigger the browser help in other ways, or even by just focusing
the address bar or other parts of the browser and hitting F1).
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: Miriam Fukushima
Date: Tue, Jul 09 2019 3:20AM
Subject: Re: Web application - shortcut to manual
← Previous message | Next message →
Thank you very much.
That is the criteria I was referring to.
Can a shortcut key then be considered as an alternative for the visual
button? So that the button doesn't have to be accessible, only for mouse
users.
Because the visual indicator is a requirement of the application's
concept, too.
Kind regards, Miriam
On 09.07.2019 10:25, Patrick H. Lauke wrote:
> On 09/07/2019 08:30, Miriam Fukushima wrote:
>
>> And if we provide a shortcut key, we also have to provide the option
>> to change this to any other key as this is one criteria in the German
>> equivalent of WCAG.
>
> Just on that point, I assume you're referring to
> https://testen.bitv-test.de/index.php?a=di&iid=112&s=n which is the
> BITV inclusion of WCAG 2.1 2.1.4 Character Key Shortcuts
> https://www.w3.org/TR/WCAG21/#character-key-shortcuts
>
> Note that if you were going to go with F1, that key is exempt from the
> requirement of 2.1.4, which only relates to printable characters (and
> there's text in the BITV test procedure there to clarify that the
> F1-F12 keys don't fall under the test).
>
> As for "hijacking" the F1 to provide help for the web site/app and
> overriding the browser's F1 help, I'd say that's a mild/minor point,
> and as long as it's explained to the user, it's acceptable (and they
> can still trigger the browser help in other ways, or even by just
> focusing the address bar or other parts of the browser and hitting F1).
>
> P
From: Patrick H. Lauke
Date: Tue, Jul 09 2019 3:45AM
Subject: Re: Web application - shortcut to manual
← Previous message | Next message →
On 09/07/2019 10:20, Miriam Fukushima wrote:
> Thank you very much.
>
> That is the criteria I was referring to.
>
> Can a shortcut key then be considered as an alternative for the visual
> button? So that the button doesn't have to be accessible, only for mouse
> users.
>
> Because the visual indicator is a requirement of the application's
> concept, too.
Nominally, I think that yes, you can argue that while the visible button
is not keyboard-focusable/actionable (I assume), the same functionality
can be triggered using the keyboard by pressing F1, so 2.1.1 Keyboard is
nominally satisfied.
However, it may be confusing for sighted/partially-sighted keyboard
users nonetheless.
It probably depends on how long/complex the form is. If it's only a
handful of fields, I'd say that perhaps having an actual focusable
button next to each field that triggers the help is ok (even though it
adds a few extra tab stops). Whereas if the form is very long, doubling
the number of focus stops needed to complete it may end up
harming/inconveniencing keyboard users again as well. This is possibly
something that falls more in the usability/user testing side of the
debate...
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: Miriam Fukushima
Date: Tue, Jul 09 2019 10:51AM
Subject: Re: Web application - shortcut to manual
← Previous message | No next message
Thank you so much for the clarification. That helped a lot!
Kind regards, Miriam
On 09.07.2019 11:45, Patrick H. Lauke wrote:
> On 09/07/2019 10:20, Miriam Fukushima wrote:
>> Thank you very much.
>>
>> That is the criteria I was referring to.
>>
>> Can a shortcut key then be considered as an alternative for the
>> visual button? So that the button doesn't have to be accessible, only
>> for mouse users.
>>
>> Because the visual indicator is a requirement of the application's
>> concept, too.
>
> Nominally, I think that yes, you can argue that while the visible
> button is not keyboard-focusable/actionable (I assume), the same
> functionality can be triggered using the keyboard by pressing F1, so
> 2.1.1 Keyboard is nominally satisfied.
>
> However, it may be confusing for sighted/partially-sighted keyboard
> users nonetheless.
>
> It probably depends on how long/complex the form is. If it's only a
> handful of fields, I'd say that perhaps having an actual focusable
> button next to each field that triggers the help is ok (even though it
> adds a few extra tab stops). Whereas if the form is very long,
> doubling the number of focus stops needed to complete it may end up
> harming/inconveniencing keyboard users again as well. This is possibly
> something that falls more in the usability/user testing side of the
> debate...
>
> P