E-mail List Archives
Thread: I have a question on focus. Not Visual Focus
Number of posts in this thread: 5 (In chronological order)
From: Nancy Johnson
Date: Fri, Sep 25 2015 11:48AM
Subject: I have a question on focus. Not Visual Focus
No previous message | Next message →
I work on highly interactive sites with a team of engineers.
Issue one: Server Side submit, and total page refresh, how can I get
the screen reader to read the success or error messaging instead of
going to the top of the page? Live Regions don't always work?
Issue two: Client-side submits: We are building a complex application
where we are using jQuery tabs to navigate through a Step process
Currently Steps two through 5 takes the user to the first field on
each step instead of the tab, with the final step goes to a Preview
page and the focus goes to the Submit at the bottom. Under the hood,
physically the entire application is one page with includes until it
submits to the databasae. The Preview is physically using the same
.jsp's as the Steps with the data retained for review.
The focus on each tab goes to the first field and the non-visual user
will miss all the instructions before the first field. I also had
trouble getting NVDA, screen reader out of tabs mode to read mode.
(Not an expert).
Other than that this application meets most of the WCAG 2.0 AA
requirements...It reads and focuses correctly on client-side error
handling which I am very pleased about.
Any suggestions on the server side submit AND better client side focus?
Are there any good tutorials geared for developers and engineers
working on complex interactive sites and WCAG 2.0 AA rating?
There is some talk of moving to Angular in the future.
Thanks
Nancy
From: Robert Fentress
Date: Fri, Sep 25 2015 2:39PM
Subject: Re: I have a question on focus. Not Visual Focus
← Previous message | Next message →
Hi, Nancy.
By server-side submit, do you mean just a standard form submit, while, for
the client-side submit, you are referring to submitting data and altering
the page using AJAX or something like that? If so, here is my take:
*Issue One*
If you are submitting a form that results in a page refresh, I don't know
that you need to have the error message read actively using anything like a
live region. If the user submits a form, won't they just read through the
page until they come to either a success or fail message? This would be
the expected behavior on a form submit. If you have a well structured page
with headings, ARIA landmarks, and/or HTML5 sectioning elements, the user
should be able to find out quickly if they succeeded. The only time you'd
need to notify the user more intrusively is if you are dynamically updating
the page. That's my take, anyway.
*Issue Two*
If there is content above the field for a step in the wizard, I would think
the best thing to do would be to place focus on the heading for that step
(the heading being made focusable by using tabindex="-1"), rather than the
first field in the step. If you had to do this for any of the steps, I
would do it for all of them, so users would know what to expect. This is
assuming you get to the step by hitting the "Next" button, rather than
navigating by tab.
Alternately, you could put the "Next" button outside the updating content,
in which case, you would not need to set focus at all, which some people
may prefer, since it is less intrusive. In that instance, an ARIA live
region might be used to announce that you had successfully moved to the
next step.
Another option, if you are set on setting focus to the first field in the
step, is to add the aria-described attribute to the field and point that at
the id of the container for your instructions (
http://www.w3.org/TR/WCAG20-TECHS/ARIA1.html). In the screen readers I
have tested this on, though, the aria-describedby attribute is only read
after a pause, so that could be easily missed.
Assuming you are using jQuery UI for your tabs, the issue you are having
with changing modes may be that once you have tabbed to the tablist
composite control, you are automatically placed in Focus mode (the tabs
mode you mentioned), and the arrow keypress events are intercepted by
JavaScript and used to set focus to the different tabs, cycling around to
the beginning of the tablist when the end is reached and vice versa. This
behavior is similar to how radio buttons are handled natively and is the
recommended behavior in the ARIA Authoring Practices (
http://www.w3.org/WAI/PF/aria-practices/). To read the tab panel contents,
without having to backtrack from whatever the next focusable item is beyond
the tablist (if any), you will need to manually exit Forms mode and return
to Browse mode (your read mode) by pressing NVDA+Space (NVDA a variable
standing for the Insert key or Caps Lock key depending on how you have
configured NVDA).
Hope that makes sense, and that I am not horribly misunderstanding your
questions/issues.
Best,
Rob
On Fri, Sep 25, 2015 at 1:48 PM, Nancy Johnson < = EMAIL ADDRESS REMOVED = > wrote:
> I work on highly interactive sites with a team of engineers.
>
> Issue one: Server Side submit, and total page refresh, how can I get
> the screen reader to read the success or error messaging instead of
> going to the top of the page? Live Regions don't always work?
>
> Issue two: Client-side submits: We are building a complex application
> where we are using jQuery tabs to navigate through a Step process
> Currently Steps two through 5 takes the user to the first field on
> each step instead of the tab, with the final step goes to a Preview
> page and the focus goes to the Submit at the bottom. Under the hood,
> physically the entire application is one page with includes until it
> submits to the databasae. The Preview is physically using the same
> .jsp's as the Steps with the data retained for review.
>
> The focus on each tab goes to the first field and the non-visual user
> will miss all the instructions before the first field. I also had
> trouble getting NVDA, screen reader out of tabs mode to read mode.
> (Not an expert).
>
> Other than that this application meets most of the WCAG 2.0 AA
> requirements...It reads and focuses correctly on client-side error
> handling which I am very pleased about.
>
> Any suggestions on the server side submit AND better client side focus?
> Are there any good tutorials geared for developers and engineers
> working on complex interactive sites and WCAG 2.0 AA rating?
>
> There is some talk of moving to Angular in the future.
>
> Thanks
>
> Nancy
> > > > >
--
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255
Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061
From: Robert Fentress
Date: Fri, Sep 25 2015 2:44PM
Subject: Re: I have a question on focus. Not Visual Focus
← Previous message | Next message →
I said "manually exit Forms mode" below, when I meant to say "manually exit
Focus mode" Focus mode in JAWS is roughly equivalent to Forms mode in
JAWS, as you may know.
Best,
Rob
On Fri, Sep 25, 2015 at 4:39 PM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
> Hi, Nancy.
>
> By server-side submit, do you mean just a standard form submit, while, for
> the client-side submit, you are referring to submitting data and altering
> the page using AJAX or something like that? If so, here is my take:
>
> *Issue One*
> If you are submitting a form that results in a page refresh, I don't know
> that you need to have the error message read actively using anything like a
> live region. If the user submits a form, won't they just read through the
> page until they come to either a success or fail message? This would be
> the expected behavior on a form submit. If you have a well structured page
> with headings, ARIA landmarks, and/or HTML5 sectioning elements, the user
> should be able to find out quickly if they succeeded. The only time you'd
> need to notify the user more intrusively is if you are dynamically updating
> the page. That's my take, anyway.
>
> *Issue Two*
> If there is content above the field for a step in the wizard, I would
> think the best thing to do would be to place focus on the heading for that
> step (the heading being made focusable by using tabindex="-1"), rather than
> the first field in the step. If you had to do this for any of the steps, I
> would do it for all of them, so users would know what to expect. This is
> assuming you get to the step by hitting the "Next" button, rather than
> navigating by tab.
>
> Alternately, you could put the "Next" button outside the updating content,
> in which case, you would not need to set focus at all, which some people
> may prefer, since it is less intrusive. In that instance, an ARIA live
> region might be used to announce that you had successfully moved to the
> next step.
>
> Another option, if you are set on setting focus to the first field in the
> step, is to add the aria-described attribute to the field and point that at
> the id of the container for your instructions (
> http://www.w3.org/TR/WCAG20-TECHS/ARIA1.html). In the screen readers I
> have tested this on, though, the aria-describedby attribute is only read
> after a pause, so that could be easily missed.
>
> Assuming you are using jQuery UI for your tabs, the issue you are having
> with changing modes may be that once you have tabbed to the tablist
> composite control, you are automatically placed in Focus mode (the tabs
> mode you mentioned), and the arrow keypress events are intercepted by
> JavaScript and used to set focus to the different tabs, cycling around to
> the beginning of the tablist when the end is reached and vice versa. This
> behavior is similar to how radio buttons are handled natively and is the
> recommended behavior in the ARIA Authoring Practices (
> http://www.w3.org/WAI/PF/aria-practices/). To read the tab panel
> contents, without having to backtrack from whatever the next focusable item
> is beyond the tablist (if any), you will need to manually exit Forms mode
> and return to Browse mode (your read mode) by pressing NVDA+Space (NVDA a
> variable standing for the Insert key or Caps Lock key depending on how you
> have configured NVDA).
>
> Hope that makes sense, and that I am not horribly misunderstanding your
> questions/issues.
>
> Best,
> Rob
>
> On Fri, Sep 25, 2015 at 1:48 PM, Nancy Johnson < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> I work on highly interactive sites with a team of engineers.
>>
>> Issue one: Server Side submit, and total page refresh, how can I get
>> the screen reader to read the success or error messaging instead of
>> going to the top of the page? Live Regions don't always work?
>>
>> Issue two: Client-side submits: We are building a complex application
>> where we are using jQuery tabs to navigate through a Step process
>> Currently Steps two through 5 takes the user to the first field on
>> each step instead of the tab, with the final step goes to a Preview
>> page and the focus goes to the Submit at the bottom. Under the hood,
>> physically the entire application is one page with includes until it
>> submits to the databasae. The Preview is physically using the same
>> .jsp's as the Steps with the data retained for review.
>>
>> The focus on each tab goes to the first field and the non-visual user
>> will miss all the instructions before the first field. I also had
>> trouble getting NVDA, screen reader out of tabs mode to read mode.
>> (Not an expert).
>>
>> Other than that this application meets most of the WCAG 2.0 AA
>> requirements...It reads and focuses correctly on client-side error
>> handling which I am very pleased about.
>>
>> Any suggestions on the server side submit AND better client side focus?
>> Are there any good tutorials geared for developers and engineers
>> working on complex interactive sites and WCAG 2.0 AA rating?
>>
>> There is some talk of moving to Angular in the future.
>>
>> Thanks
>>
>> Nancy
>> >> >> >> >>
>
>
>
> --
> Robert Fentress
> Senior Accessibility Solutions Designer
> 540.231.1255
>
> Technology-enhanced Learning & Online Strategies
> Assistive Technologies
> 1180 Torgersen Hall
> 620 Drillfield Drive (0434)
> Blacksburg, Virginia 24061
>
--
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255
Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061
From: Nancy Johnson
Date: Mon, Sep 28 2015 7:16AM
Subject: Re: I have a question on focus. Not Visual Focus
← Previous message | Next message →
Thank you. This information is very helpful information.
Nancy
On Fri, Sep 25, 2015 at 4:44 PM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
> I said "manually exit Forms mode" below, when I meant to say "manually exit
> Focus mode" Focus mode in JAWS is roughly equivalent to Forms mode in
> JAWS, as you may know.
>
> Best,
> Rob
>
> On Fri, Sep 25, 2015 at 4:39 PM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hi, Nancy.
>>
>> By server-side submit, do you mean just a standard form submit, while, for
>> the client-side submit, you are referring to submitting data and altering
>> the page using AJAX or something like that? If so, here is my take:
>>
>> *Issue One*
>> If you are submitting a form that results in a page refresh, I don't know
>> that you need to have the error message read actively using anything like a
>> live region. If the user submits a form, won't they just read through the
>> page until they come to either a success or fail message? This would be
>> the expected behavior on a form submit. If you have a well structured page
>> with headings, ARIA landmarks, and/or HTML5 sectioning elements, the user
>> should be able to find out quickly if they succeeded. The only time you'd
>> need to notify the user more intrusively is if you are dynamically updating
>> the page. That's my take, anyway.
>>
>> *Issue Two*
>> If there is content above the field for a step in the wizard, I would
>> think the best thing to do would be to place focus on the heading for that
>> step (the heading being made focusable by using tabindex="-1"), rather than
>> the first field in the step. If you had to do this for any of the steps, I
>> would do it for all of them, so users would know what to expect. This is
>> assuming you get to the step by hitting the "Next" button, rather than
>> navigating by tab.
>>
>> Alternately, you could put the "Next" button outside the updating content,
>> in which case, you would not need to set focus at all, which some people
>> may prefer, since it is less intrusive. In that instance, an ARIA live
>> region might be used to announce that you had successfully moved to the
>> next step.
>>
>> Another option, if you are set on setting focus to the first field in the
>> step, is to add the aria-described attribute to the field and point that at
>> the id of the container for your instructions (
>> http://www.w3.org/TR/WCAG20-TECHS/ARIA1.html). In the screen readers I
>> have tested this on, though, the aria-describedby attribute is only read
>> after a pause, so that could be easily missed.
>>
>> Assuming you are using jQuery UI for your tabs, the issue you are having
>> with changing modes may be that once you have tabbed to the tablist
>> composite control, you are automatically placed in Focus mode (the tabs
>> mode you mentioned), and the arrow keypress events are intercepted by
>> JavaScript and used to set focus to the different tabs, cycling around to
>> the beginning of the tablist when the end is reached and vice versa. This
>> behavior is similar to how radio buttons are handled natively and is the
>> recommended behavior in the ARIA Authoring Practices (
>> http://www.w3.org/WAI/PF/aria-practices/). To read the tab panel
>> contents, without having to backtrack from whatever the next focusable item
>> is beyond the tablist (if any), you will need to manually exit Forms mode
>> and return to Browse mode (your read mode) by pressing NVDA+Space (NVDA a
>> variable standing for the Insert key or Caps Lock key depending on how you
>> have configured NVDA).
>>
>> Hope that makes sense, and that I am not horribly misunderstanding your
>> questions/issues.
>>
>> Best,
>> Rob
>>
>> On Fri, Sep 25, 2015 at 1:48 PM, Nancy Johnson < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> I work on highly interactive sites with a team of engineers.
>>>
>>> Issue one: Server Side submit, and total page refresh, how can I get
>>> the screen reader to read the success or error messaging instead of
>>> going to the top of the page? Live Regions don't always work?
>>>
>>> Issue two: Client-side submits: We are building a complex application
>>> where we are using jQuery tabs to navigate through a Step process
>>> Currently Steps two through 5 takes the user to the first field on
>>> each step instead of the tab, with the final step goes to a Preview
>>> page and the focus goes to the Submit at the bottom. Under the hood,
>>> physically the entire application is one page with includes until it
>>> submits to the databasae. The Preview is physically using the same
>>> .jsp's as the Steps with the data retained for review.
>>>
>>> The focus on each tab goes to the first field and the non-visual user
>>> will miss all the instructions before the first field. I also had
>>> trouble getting NVDA, screen reader out of tabs mode to read mode.
>>> (Not an expert).
>>>
>>> Other than that this application meets most of the WCAG 2.0 AA
>>> requirements...It reads and focuses correctly on client-side error
>>> handling which I am very pleased about.
>>>
>>> Any suggestions on the server side submit AND better client side focus?
>>> Are there any good tutorials geared for developers and engineers
>>> working on complex interactive sites and WCAG 2.0 AA rating?
>>>
>>> There is some talk of moving to Angular in the future.
>>>
>>> Thanks
>>>
>>> Nancy
>>> >>> >>> >>> >>>
>>
>>
>>
>> --
>> Robert Fentress
>> Senior Accessibility Solutions Designer
>> 540.231.1255
>>
>> Technology-enhanced Learning & Online Strategies
>> Assistive Technologies
>> 1180 Torgersen Hall
>> 620 Drillfield Drive (0434)
>> Blacksburg, Virginia 24061
>>
>
>
>
> --
> Robert Fentress
> Senior Accessibility Solutions Designer
> 540.231.1255
>
> Technology-enhanced Learning & Online Strategies
> Assistive Technologies
> 1180 Torgersen Hall
> 620 Drillfield Drive (0434)
> Blacksburg, Virginia 24061
> > > >
From: Robert Fentress
Date: Tue, Sep 29 2015 7:17AM
Subject: Re: I have a question on focus. Not Visual Focus
← Previous message | No next message
You're welcome.
I caught another typo. I wrote "Another option, if you are set on setting
focus to the first field in the step, is to add the aria-described
attribute..." The correct attribute name is "aria-describedby", not
"aria-described". If you go this route, then you *may* want to add
aria-hidden to the container with the instructions. If you don't, then the
instructions may be read (at least) twice, depending on the mode and the
way the user navigates the pane containing the step. This all depends on
your exact use case. If the instructions are only related to that
particular field you are moving focus to, then this *might* be an okay
strategy. However, if the same instructions relate to multiple fields,
this approach would be problematic, since you'd then probably want to add
the aria-describedby to all those other fields, which would be too
verbose. The long and short of it is that the aria-describedby approach is
probably not the best one.
As an aside, the content referenced by aria-describedby is read after a
pause in OS X with VoiceOver/Safari. In JAWS 15 and NVDA 2015.3, it is
read immediately after the label, but only when in Forms/Focus mode.
Best,
Rob
On Mon, Sep 28, 2015 at 9:16 AM, Nancy Johnson < = EMAIL ADDRESS REMOVED = > wrote:
> Thank you. This information is very helpful information.
>
> Nancy
>
> On Fri, Sep 25, 2015 at 4:44 PM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
> > I said "manually exit Forms mode" below, when I meant to say "manually
> exit
> > Focus mode" Focus mode in JAWS is roughly equivalent to Forms mode in
> > JAWS, as you may know.
> >
> > Best,
> > Rob
> >
> > On Fri, Sep 25, 2015 at 4:39 PM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> Hi, Nancy.
> >>
> >> By server-side submit, do you mean just a standard form submit, while,
> for
> >> the client-side submit, you are referring to submitting data and
> altering
> >> the page using AJAX or something like that? If so, here is my take:
> >>
> >> *Issue One*
> >> If you are submitting a form that results in a page refresh, I don't
> know
> >> that you need to have the error message read actively using anything
> like a
> >> live region. If the user submits a form, won't they just read through
> the
> >> page until they come to either a success or fail message? This would be
> >> the expected behavior on a form submit. If you have a well structured
> page
> >> with headings, ARIA landmarks, and/or HTML5 sectioning elements, the
> user
> >> should be able to find out quickly if they succeeded. The only time
> you'd
> >> need to notify the user more intrusively is if you are dynamically
> updating
> >> the page. That's my take, anyway.
> >>
> >> *Issue Two*
> >> If there is content above the field for a step in the wizard, I would
> >> think the best thing to do would be to place focus on the heading for
> that
> >> step (the heading being made focusable by using tabindex="-1"), rather
> than
> >> the first field in the step. If you had to do this for any of the
> steps, I
> >> would do it for all of them, so users would know what to expect. This
> is
> >> assuming you get to the step by hitting the "Next" button, rather than
> >> navigating by tab.
> >>
> >> Alternately, you could put the "Next" button outside the updating
> content,
> >> in which case, you would not need to set focus at all, which some people
> >> may prefer, since it is less intrusive. In that instance, an ARIA live
> >> region might be used to announce that you had successfully moved to the
> >> next step.
> >>
> >> Another option, if you are set on setting focus to the first field in
> the
> >> step, is to add the aria-described attribute to the field and point
> that at
> >> the id of the container for your instructions (
> >> http://www.w3.org/TR/WCAG20-TECHS/ARIA1.html). In the screen readers I
> >> have tested this on, though, the aria-describedby attribute is only read
> >> after a pause, so that could be easily missed.
> >>
> >> Assuming you are using jQuery UI for your tabs, the issue you are having
> >> with changing modes may be that once you have tabbed to the tablist
> >> composite control, you are automatically placed in Focus mode (the tabs
> >> mode you mentioned), and the arrow keypress events are intercepted by
> >> JavaScript and used to set focus to the different tabs, cycling around
> to
> >> the beginning of the tablist when the end is reached and vice versa.
> This
> >> behavior is similar to how radio buttons are handled natively and is the
> >> recommended behavior in the ARIA Authoring Practices (
> >> http://www.w3.org/WAI/PF/aria-practices/). To read the tab panel
> >> contents, without having to backtrack from whatever the next focusable
> item
> >> is beyond the tablist (if any), you will need to manually exit Forms
> mode
> >> and return to Browse mode (your read mode) by pressing NVDA+Space (NVDA
> a
> >> variable standing for the Insert key or Caps Lock key depending on how
> you
> >> have configured NVDA).
> >>
> >> Hope that makes sense, and that I am not horribly misunderstanding your
> >> questions/issues.
> >>
> >> Best,
> >> Rob
> >>
> >> On Fri, Sep 25, 2015 at 1:48 PM, Nancy Johnson < = EMAIL ADDRESS REMOVED = >
> >> wrote:
> >>
> >>> I work on highly interactive sites with a team of engineers.
> >>>
> >>> Issue one: Server Side submit, and total page refresh, how can I get
> >>> the screen reader to read the success or error messaging instead of
> >>> going to the top of the page? Live Regions don't always work?
> >>>
> >>> Issue two: Client-side submits: We are building a complex application
> >>> where we are using jQuery tabs to navigate through a Step process
> >>> Currently Steps two through 5 takes the user to the first field on
> >>> each step instead of the tab, with the final step goes to a Preview
> >>> page and the focus goes to the Submit at the bottom. Under the hood,
> >>> physically the entire application is one page with includes until it
> >>> submits to the databasae. The Preview is physically using the same
> >>> .jsp's as the Steps with the data retained for review.
> >>>
> >>> The focus on each tab goes to the first field and the non-visual user
> >>> will miss all the instructions before the first field. I also had
> >>> trouble getting NVDA, screen reader out of tabs mode to read mode.
> >>> (Not an expert).
> >>>
> >>> Other than that this application meets most of the WCAG 2.0 AA
> >>> requirements...It reads and focuses correctly on client-side error
> >>> handling which I am very pleased about.
> >>>
> >>> Any suggestions on the server side submit AND better client side focus?
> >>> Are there any good tutorials geared for developers and engineers
> >>> working on complex interactive sites and WCAG 2.0 AA rating?
> >>>
> >>> There is some talk of moving to Angular in the future.
> >>>
> >>> Thanks
> >>>
> >>> Nancy
> >>> > >>> > >>> > >>> > >>>
> >>
> >>
> >>
> >> --
> >> Robert Fentress
> >> Senior Accessibility Solutions Designer
> >> 540.231.1255
> >>
> >> Technology-enhanced Learning & Online Strategies
> >> Assistive Technologies
> >> 1180 Torgersen Hall
> >> 620 Drillfield Drive (0434)
> >> Blacksburg, Virginia 24061
> >>
> >
> >
> >
> > --
> > Robert Fentress
> > Senior Accessibility Solutions Designer
> > 540.231.1255
> >
> > Technology-enhanced Learning & Online Strategies
> > Assistive Technologies
> > 1180 Torgersen Hall
> > 620 Drillfield Drive (0434)
> > Blacksburg, Virginia 24061
> > > > > > > > > > > > >
--
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255
Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061