WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: I have a question on focus. Not Visual Focus


From: Robert Fentress
Date: Sep 25, 2015 2:39PM

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


On Fri, Sep 25, 2015 at 1:48 PM, Nancy Johnson < <EMAIL 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

Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061