WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Question on setting default focus on a page...

for

From: Patrick H. Lauke
Date: May 17, 2016 1:38PM

On 17/05/2016 20:21, Tim Harshbarger wrote:
> When I looked at SC 2.4.3, I noticed that the 3rd example mentions a modal dialog where focus is placed on the first interactable element. If that isn't a violation, then why would be doing the same on a web page be a violation?

Because a modal dialog is different from a page, and it has
established/expected patterns from its native equivalents (for instance
even if you fire up a browser-native alert() you'll see that focus is
actually placed on the OK control in most cases).

P

> on a web page also
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Mike Barlow
> Sent: Tuesday, May 17, 2016 1:34 PM
> To: <EMAIL REMOVED> ; WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Question on setting default focus on a page...
>
> Thanks Patrick/Bim that's what I was looking for (2.4.3 Focus Order
> Violation, for some reason I just couldn't find that when I went looking
> earlier)
>
> *Mike Barlow*
> Web Application Developer
> Web Accessibility/Section 508 SME
>
> Lancaster, Pa 17601
> Office: 732.835-7557
> Cell: 732.682.8226
> e-mail: <EMAIL REMOVED>
>
> On Tue, May 17, 2016 at 1:43 PM, Bim Egan < <EMAIL REMOVED> > wrote:
>
>> All good points so far, here's my take. When a screenreader user lands on
>> a
>> page where focus is put into the first form field:
>> A) There's a perplexing volume of information coming their way. The reader
>> will announce the page title, how many headings there are and how many
>> regions . It may or may not read the field label and the screenreader is
>> put
>> into forms mode. Forms mode can be a tone or a voiced notification;
>> B) It's confusing when exactly the same thing happens if the user lands on
>> a
>> page in an element that puts the screenreader into application mode. In my
>> screenreaders the audible signals that forms mode is invoked are identical
>> to the application mode tones. .
>>
>> So the user's left not being sure which keys to press. The volume of
>> landing output could obscure the field label announcement or any voiced
>> forms mode notification, so they may well start using keyboard shortcuts
>> for
>> headings or regions. (Can't tell you how many times I've typed H1 into a
>> field trying to get to the main content heading).
>>
>> If the aim is to make it easy for keyboard only users to reach the start of
>> the form, a skip link would do the trick. If it's to make it quicker for a
>> mouse user to click into the first field ... The price is too high.
>>
>> I agree with Patrick that this is, (or certainly should be), a 2.4.3 focus
>> order violation.
>>
>> Best,
>> Bim
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
>> Of Joseph Sherman
>> Sent: 17 May 2016 17:33
>> To: 'WebAIM Discussion List'
>> Subject: Re: [WebAIM] Question on setting default focus on a page...
>>
>> I think it depends. If it's a page that is a continuation of a form being
>> filled out, and there is no information on the page prior to the input
>> field
>> receiving focus, it seems reasonable to start focus on the field. But if
>> there is information or instruction that is missed or the user will be
>> surprised to find themselves in a form field that would be a problem.
>>
>>
>> Joseph
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
>> Of Patrick H. Lauke
>> Sent: Tuesday, May 17, 2016 11:40 AM
>> To: <EMAIL REMOVED>
>> Subject: Re: [WebAIM] Question on setting default focus on a page...
>>
>> On 17/05/2016 15:12, Mike Barlow wrote:
>>> One of my contacts just brought up something I hadn't heard of before.
>>> They have a form that they set the default focus to the first input
>>> field on the form but was told that was a violation because screen
>>> readers would not read the top of the page if the focus was set into a
>>> field. Now, I haven't tested the screen reader doing that, but I'm
>>> pretty sure that's correct (that's pretty much how the "Skip
>>> Navigation" works). However, I'm not certain if that is really a
>>> violation or not (don't recall any particular Guideline that addresses
>> that particular issue).
>>
>> Arguably it's related to 2.4.3 Focus Order
>>
>> https://www.w3.org/TR/2008/REC-WCAG20-20081211/#navigation-mechanisms-focus-
>> order
>> - and more generally, a user may not be aware that they have been moved
>> somewhere other than the start of the document, so may not be aware that
>> there were other elements/content prior to their position.
>>
>> 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
>> >> >> at
>> http://webaim.org/discussion/archives
>> >> >> >> at
>> http://webaim.org/discussion/archives
>> >>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2016.0.7597 / Virus Database: 4568/12246 - Release Date: 05/17/16
>>
>> >> >> >> >>
> > > > > > > > >


--
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