Screen reader only content, and html doctypes
Rich Caloggero
http://www.mit.edu/~rjc/liveRegions/definitions-doctype.html
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:
http://adaptivethemes.com/using-css-clip-as-an-accessible-method-of-hiding-content
Comments please...
-- Rich
David Bolter
The definitions-doctype example seems to be a dead link?
Cheers,
David
On Sep 28, 3:55 pm, "Rich Caloggero" <r...@MIT.EDU> wrote:
> http://www.mit.edu/~rjc/liveRegions/definitions.htmlhttp://www.mit.edu/~rjc/liveRegions/definitions-doctype.html
> 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
>
> Comments please...
> -- Rich
Rich Caloggero
definition to 1. The odd thing about this is that, using Jaws at least, a
file with no doctype would still hide the content from the screen, while
using a correct doctype jaws seemed to show pieces of the off-screen
content.
.screenReaderOnly {
position: absolute;
height: 1; /* should be 0 */
left: -9999; /* what's the difference with off-left vs. off-top (top:-9999)?
*/
overflow: hidden;
}
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
supplied.
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
issues?
Are the timing issues real, or am I missing something completely here?
-- Rich
Hi Rich,
Cheers,
David
--
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
jquery-a11y...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-a11y?hl=en.
David Bolter
A general note on my understanding of how aria-live is intended to
work. The container element on which aria-live is specified should be
in the DOM before child nodes are added or removed if you expect such
adds/removes to be reacted to. I think in your example the whole
dialog is atomically added to the DOM.
It is awesome that you are making sure this works with at least two
AT. That said, it seems to me that the use of offscreen text is a red
flag, indicating a weakness in our specifications. Have you tried aria-
label etc?
Cheers,
David
Rich Caloggero
A client was using jQuery-ui's accordion widgit. The widgit uses markup
like this:
<div class="accordion">
<h2>trigger1</h2>
<div><p>Content 1</p></div>
<h2>trigger2</h2>
<div><p>Content 2</p></div>
</div>
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
divs.
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
navigation.
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.
-- Rich
David Bolter
hear from screen reader devs. I'll blabber for a bit though...
There is no limit to the complexity one could introduce when creating
rules to reconcile native html semantics with aria semantics. The
browser ARIA implementation group has agreed on the general rule that
ARIA always overrides (even though the rule complexity is going ahead
in other working groups). With Firefox, the element tag name will
always be exposed via IA2 object attributes even if the role is
overridden by aria, so in a sense we've left this up to the AT. That
said, I am confident that the AT cannot always make the right choice
no matter how many CPU cycles it spins.
Cheers,
David
Rich Caloggero
Colin Clark
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?
Colin
---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org
Rich Caloggero
>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
>experience?
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.
-- Rich
Hi Rich,
Colin
--
Rich Caloggero
public server:
http://www.mit.edu/~rjc/www/aria/
Comments encouraged.