At each of the two above urls, I've placed a simple page which uses
jQuery-ui to create a tabbed interface. I wanted a screen reader friendly
way of showing which tab is active, without changing the visual display.
TO do this, I wrote a callback which I attach to the tabshow event. It adds
some text to the current tab indicating it is active, and uses CSS to move
this text off-screen.
The issue seems to be that when a doctype definition is used, the CSS fails,
and part of the text shows up in the tabs list. Any CSS gurus out there
know what's going on?
Perhaps answers can be found in this article, which introduces a technique
new to me which uses CSS clip to move objects off-screen:
height: 1; /* should be 0 */
left: -9999; /* what's the difference with off-left vs. off-top (top:-9999)?
Was also wondering about dialogs.html in the same directory. I've found that
the alertdialog role does not actually speak the dialog text. It does cause
the screen reader to announce the fact that the dialog appeared (at least
most of the time), but using Jaws and nvda, was never ablt to reliably get
either to read the dialog content.
To that end, I've done the following which seems to work:
1. placed aria-live="assertive" (polite works as well) on the dialog content
which you initially pass to .dialog();
2. in the dialogopen event callback, simply rewrite the content initially
When the dialog initially appears (is unhidden), the live region is not
triggered because it takes time for the browser and the screen reader to
realize that the dialog has been unhidden. WHen the callback is actually
called, the dialog has been fully unhidden and thus the liveregion markup
will be acted upon correctly.
Question: does this cause cany sort of visual weirdness when the content is
rewritten? WOuld this be a reliable method to work around the timing
Are the timing issues real, or am I missing something completely here?
You received this message because you are subscribed to the Google Groups
"jQuery Accessibility" group.
To post to this group, send email to jquer...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at
A client was using jQuery-ui's accordion widgit. The widgit uses markup
The widgit sets this up like a tabbed interface; a role="tablist" is placed
on the parent div, role="tab" on the h2s, and role="tabpanel" on the content
The issue here is that:
1. role="tab" on the triggers causes both Jaws and NVDA to completely ignore
the fact that these are heading elements. It calls them "tabs" and throws
away the heading semantics - i.e. they are no longer in the screen reader's
headings list and cannot be navigated to via the "h" and shift+h keys. For
small example, this matters not; for examples where the length of the
content in the content divs is significant, headings can be very useful for
Another annoying thing is that the screen reader shifts into "application"
mode when role="tab" is encountered. This makes it difficult to read the
content and could very much confuse nontechnical screen reader users. This
is mitigated somewhat by the fact that the entire accordion is now treated
like a live region, and the AT tries to speak the content of the content
panel that was just opened, but this is *not* appropriate if the content is
very long or requires careful reading.
Question: is this a screen reader bug, or the browser throwing away heading
semantics in favor of the newly assigned role? Should elements be able to
have more than one role (i.e. this h2 element is now a heading and a tab)?
Live regions are extremely useful, but I think they should be used
sparingly. I don't think live region semantics should come along with role
definitions, except in a few isolated situations (alertdialog is one which
could be very useful if it only worked). In general, the developer should
know exactly how much content should change at any give time, so should be
able to specify exactly how much should be announced via live regions as
possible; having this done for you by the role semantics will most like
result in way too much chatter from the screen reader.
Just my two cents... Would love to hear other's thoughts on this.
A follow up question to your experiments with the tab role and jQuery UI's accordion widget. What happens if the contents of the accordion is wrapped in a "document" role? This should, in theory, cue the screen reader to switch out of its application mode when focus moves into the actual content.
As for the issue of tabs no longer being represented as headers: would wrapping the tabs in a navigation landmark provide a comparable user experience?
Technical Lead, Fluid Project
>What happens if the contents of the accordion is wrapped in a "document"
>role? This should, in theory, cue the screen reader to switch out of its
>application mode when focus moves into the actual content.
Neither Jaws nor NVDA handle this correctly.
The stock accordion as supplied by jQuery-ui shows itself in document mode,
but as soon as you begin interacting with it (i.e. press enter when focused
on one of the tabs) the screen reader switches to applications mode.
Wrapping the entire accordion div inside another with role="document", as
well as placing a document role on the same div that contains the accordion
does not change this behavior.
>As for the issue of tabs no longer being represented as headers: would
>wrapping the tabs in a navigation landmark provide a comparable user
This helps in the sense that it does add back the ability to move from tab
to tab while in document mode, but as soon as you begin interacting with the
accordion, you switch into application mode.
The other weird thing is that Jaws gets confused when more than one role is
associated with an element. In this case, adding a role="navigation" to each
tab removes the semantics for role="tab" and now jaws calls it a navigation
landmark and an h3 tag. Since all the tab semantics are gone, it will not
report on open/closed state. NVDA keeps the tab semantics, adds landmark
semantics (you can move among landmarks with "d" and shift+d in NVDA), but
will still not recognize them as heading tags. So, in short, NVDA exhibits
something more akin to "correct" behavior; Jaws does not!
Another weird Jaws bug is that the mere existance of a role attribute forces
a linefeed in the virtual buffer, even though the role does not modify the
virtual buffer. For example, adding a role="alert" to an element will cause
a line break in the virtual buffer at the point where this element resides,
even if this is an inline element such as span.
I still would like to see the original role of heading kept, even if the
element's role has been assigned, but neither screen reader does this.
Hope this helps.