E-mail List Archives

Search E-mail List Archives for

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

From: Mike Barlow
Date: Tue, May 17 2016 8:12AM
Subject: Question on setting default focus on a page...
No previous message | Next message →

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

Any thoughts/help?

Thanks
*Mike Barlow*
Web Application Developer
Web Accessibility/Section 508 SME

Lancaster, Pa 17601
Office: 732.835-7557
Cell: 732.682.8226
e-mail: = EMAIL ADDRESS REMOVED =

From: Patrick H. Lauke
Date: Tue, May 17 2016 9:39AM
Subject: Re: Question on setting default focus on a page...
← Previous message | Next message →

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

From: Maxability Accessibility for all
Date: Tue, May 17 2016 10:22AM
Subject: Re: Question on setting default focus on a page...
← Previous message | Next message →

It may be a violation in most cases but in certain situations focus will be
set to a particular element on the page purposefully. Eg: On www.google.com
default focus moves to the search field. Do we ask the customer to change
this behavior referring to accessibility guidelines?

Thanks & Regards
Rakesh



On Tue, May 17, 2016 at 9:09 PM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

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

From: Patrick H. Lauke
Date: Tue, May 17 2016 10:30AM
Subject: Re: Question on setting default focus on a page...
← Previous message | Next message →

As with most SCs, whether it's a pass or a fail will depend on the
specific situation (for instance, how much "stuff" was actually skipped
over when the focus was set further down in the page). Your mileage may
vary...

P

On 17/05/2016 17:22, Maxability Accessibility for all wrote:
> It may be a violation in most cases but in certain situations focus will be
> set to a particular element on the page purposefully. Eg: On www.google.com
> default focus moves to the search field. Do we ask the customer to change
> this behavior referring to accessibility guidelines?
>
> Thanks & Regards
> Rakesh
>
>
>
> On Tue, May 17, 2016 at 9:09 PM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> 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
>>
>> >> >> >> >>
> > > > >


--
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: Joseph Sherman
Date: Tue, May 17 2016 10:33AM
Subject: Re: Question on setting default focus on a page...
← Previous message | Next message →

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

From: Bim Egan
Date: Tue, May 17 2016 11:43AM
Subject: Re: Question on setting default focus on a page...
← Previous message | Next message →

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

From: Mike Barlow
Date: Tue, May 17 2016 12:33PM
Subject: Re: Question on setting default focus on a page...
← Previous message | Next message →

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 ADDRESS REMOVED =

On Tue, May 17, 2016 at 1:43 PM, Bim Egan < = EMAIL ADDRESS 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
>
>
>

From: Tim Harshbarger
Date: Tue, May 17 2016 1:21PM
Subject: Re: Question on setting default focus on a page...
← Previous message | Next message →

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?

on a web page also

From: Patrick H. Lauke
Date: Tue, May 17 2016 1:38PM
Subject: Re: Question on setting default focus on a page...
← Previous message | Next message →

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

From: KP
Date: Tue, May 17 2016 1:45PM
Subject: Re: Question on setting default focus on a page...
← Previous message | No next message

It's been covered but definitely in my mind it's context dependent. Google is a bad example as that's an exception that breaks the rule but is widely understood.

If it's the next step in a form ie split into pages for visual comfort then absolutely the first firm field or heading is right. It's part of a process and your aim, sighted or not, is on filling it out.

Kevin

Sent from my iPhone

> On 18/05/2016, at 7:38 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
>> 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
>>
>>
>>