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 29, 2015 7:17AM

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 REMOVED> > wrote:

> 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
> > > > > > > > > > > > >



--
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