E-mail List Archives

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


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

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.


On Fri, Sep 25, 2015 at 4:39 PM, Robert Fentress < <EMAIL 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 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

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