WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Nancy Johnson
Date: Sep 28, 2015 7:16AM

Thank you. This information is very helpful information.

Nancy

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