WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Keyboard Access in DHS Trusted Program Website

for

Number of posts in this thread: 3 (In chronological order)

From: Hari Krishna
Date: Tue, Aug 25 2020 3:59AM
Subject: Keyboard Access in DHS Trusted Program Website
No previous message | Next message →

Hello All,

This is regarding Keyboard Access
<https://training.section508testing.net/mod/book/view.php?id=1229&chapterid=2671>
in
DHS Trusted Tester Program. This rule says that "This Test Condition DOES
NOT APPLY (DNA) if the page has no user-activated functionality. (This is
not usual.)".

Suppose if I have a webpage in which there is a single frame with a large
content(plain text) and the frame width and height is fixed. So a mouse
user can access the whole content by scrolling the frame but there is no
option for the keyboard user.

Will it be a violation of this Keyboard Access or this does not apply as
there is no user-activated functionality on the page ?

Thanks in advance!!
Hari

From: Patrick H. Lauke
Date: Tue, Aug 25 2020 4:27AM
Subject: Re: Keyboard Access in DHS Trusted Program Website
← Previous message | Next message →

On 25/08/2020 10:59, Hari Krishna wrote:
> Hello All,
>
> This is regarding Keyboard Access
> <https://training.section508testing.net/mod/book/view.php?id=1229&chapterid=2671>
> in
> DHS Trusted Tester Program. This rule says that "This Test Condition DOES
> NOT APPLY (DNA) if the page has no user-activated functionality. (This is
> not usual.)".
>
> Suppose if I have a webpage in which there is a single frame with a large
> content(plain text) and the frame width and height is fixed. So a mouse
> user can access the whole content by scrolling the frame but there is no
> option for the keyboard user.
>
> Will it be a violation of this Keyboard Access or this does not apply as
> there is no user-activated functionality on the page ?

Not an expert in Trusted Tester itself, but purely from a WCAG 2.1 point
of view, this would fail 2.1.1 if there's no way for a keyboard user to
scroll. I'd say the scrolling/need to scroll is a "user-activated
functionality". Arguably, browsers should handle this gracefully
themselves (see for instance Firefox, which automatically makes an
<iframe> - I assume you're talking about iframes here? - focusable by
default, so keyboard users can always get to the iframe itself and then
use their cursor keys etc to scroll). But as that's not the case in all
browsers, authors need to consider this themselves.

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Hari Krishna
Date: Tue, Aug 25 2020 4:35AM
Subject: Re: Keyboard Access in DHS Trusted Program Website
← Previous message | No next message

Thanks Patrick for your reply!!

Yes, I was referring to iframes only.

Regards,
Hari

On Tue, Aug 25, 2020 at 3:57 PM Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

> On 25/08/2020 10:59, Hari Krishna wrote:
> > Hello All,
> >
> > This is regarding Keyboard Access
> > <
> https://training.section508testing.net/mod/book/view.php?id=1229&chapterid=2671
> >
> > in
> > DHS Trusted Tester Program. This rule says that "This Test Condition DOES
> > NOT APPLY (DNA) if the page has no user-activated functionality. (This is
> > not usual.)".
> >
> > Suppose if I have a webpage in which there is a single frame with a large
> > content(plain text) and the frame width and height is fixed. So a mouse
> > user can access the whole content by scrolling the frame but there is no
> > option for the keyboard user.
> >
> > Will it be a violation of this Keyboard Access or this does not apply as
> > there is no user-activated functionality on the page ?
>
> Not an expert in Trusted Tester itself, but purely from a WCAG 2.1 point
> of view, this would fail 2.1.1 if there's no way for a keyboard user to
> scroll. I'd say the scrolling/need to scroll is a "user-activated
> functionality". Arguably, browsers should handle this gracefully
> themselves (see for instance Firefox, which automatically makes an
> <iframe> - I assume you're talking about iframes here? - focusable by
> default, so keyboard users can always get to the iframe itself and then
> use their cursor keys etc to scroll). But as that's not the case in all
> browsers, authors need to consider this themselves.
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >