WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

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.

Best,
Rob

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
540.231.1255

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