screen readers and @aural styles [was: RE: Fw: putting reader text...]

At 04:47 PM 2001-12-03 , Phill Jenkins wrote:
>Mike, Charles, and others
>the "presentation modes" Charles referred to in the CSS spec are referring
>to "media types".  Screen readers today are reading the "visual" media type
>[CSS+HTML].  If the author marked the "visual" information as hidden, the
>screen reader should respect that attribute.  The "Aural" media type, if
>ever supported by screen readers, does not tell the screen reader what to
>do with interpreting the "Visual media" attributes.  I do not agree with
>the private interpretations that somehow suggest that media types are
>referring to presentation instructions for screen readers.  Even if a "self
>voicing browser" [not a screen reader] supported all the media types, the
>spec does not define what to do other than the assertion that the user
>agent itself decides which media types it supports.  For example, Home Page
>Reader supports the media group "visual", so it must honor the visibility:
>hidden attribute.  This should be something discussed further in WCAG 2.0,
>the Device independent working group, or a new working group for screen
>reader developers.
>
>Media types are explained in CSS at
><http://www.w3.org/TR/REC-CSS2/media.html>http://www.w3.org/TR/REC-CSS2/me
dia.html
>

AG::

If a display:none; indication is guarded by an @media:screen clause then is
the
hiding conditional?  Is that your reading of CSS?  What should an aural
rendering do with content that is hidden by such a conditional clause?

In that case an aural rendering [anything driving a speech synthesizer] should
ignore the hiding indication, according to the logic of the CSS language.
This
is how one would program conditional exposure in audio and not on the
screen in
standard CSS.  The logic is all there in the specification in the description
of how @media indications work in the cascade.

As Terje Bless pointed out, the failure mode if style is not supported is
fail-safe.  It just shows all the content, which may be a little on the
verbose
side for visual preferences, but is correct information regardless. 

Do you find this description to be in agreement with CSS or not?

Important caveat:  This is all academic for the future.  With the advantage of
hindsight, content control should _not_ be managed as style but directly as
content control in the content, c.f. html:object and smil:switch.

In the best of all possible worlds, all renderings that go to the aural medium
should recognize as appropriate to them rendering hints that are marked as
appropriate for the aural medium.  The aural renderings should emulate a
direct
rendering from the device-independent content, even if their physical
source of
data is from a module that is also doing the screen rendering.  If this is an
undue burden, maybe we do need a dedicated working group for screen reader
developers to defend their legitimate interests.

In the CSS specification it clearly says that the @aural indication is
supposed
to be "appropriate for use with speech synthesizers."  Screen readers and HPR
are both producing their output through speech synthesizers.  It also says
that
these descriptions of what constitutes a medium are suggestive, not
definitive.

In no way are screen readers supposed to be exempt from the advice that the
author gives in aural styling cues.  All styling, per WCAG 1.0 has got to be
expendable.  So the core functionality can't be dependent on HPR implementing
aural CSS.  But per the theory of the CSS spec, it would be better if it did.

All of this may be a bit naive because we did not fully appreciate the
confusion issues when content is presented in multiple modes at once, as in
Home Page Reader or SuperNova.  I am more interested in getting to a workable
future where aural-targeted hints are honored where appropriate than in
"setting the record straight."

But in the model/view/controller strategy as I believe it is implemented in
XForms, and as is assumed in the WAI input to the Device Independence group,
the logical relationship from the model to one view is concurrent with the
logical relationship between the same model and a different view.  All views
are generally derived from the common core model, and only in exceptional
cases
is a view derived from another view.

Even in the case that the aural display is derived from the screen display,
the
author's hints as to aural presentation should flow through and where possible
and the user approves, be applied.

If that model is broken, we need to start an engineering activity to develop
its replacement.

Al

>The difference I understand between display: none and visibility: hidden is
>what I call "white space".  Display: none creates no white space, no
>formatting space or box, [nothing is there], while visibility:hidden
>creates a space, but it is empty.  Not sure if there is any difference when
>it comes to a screen reader.
>
>Mike wrote:
>> "Skip Navigation" links are perfect examples of items that we might want
>> hidden but definitely should be read by a screen reader. (Instead of the
>> current work arounds like invisible images or text set to the same color
>> as the background.)
>
>There is a design debate about "definitely" as in definitely hiding the
>"Skip navigation" link.  It could be just some small text that is visible.
>But the reason we recommend the "current work around" [alt text on
>invisible images] is because it works! And it has to when CSS it turned
>off! Visibility: hidden wouldn't work with CSS off.
>
>> Also, there could be cases where dynamically hidden
>> elements (such as pop-up or expanding/collapsing menus) also should be
>> read.
>
>This is exactly why screen readers should NOT read text that is hidden by
>JavaScript.  By honoring the visibility properties affected by JavaScript,
>the JavaScript page can be made directly accessible and - more importantly
>- usable.  For example, web applications "hide" content when it is not
>pertinent to the user's profile.  Blind users should not be forced to read
>all the hidden content, usually out of order and context,  when the sighted
>users doesn't have to.
>
>Regards,
>Phill
>

Received on Tuesday, 4 December 2001 18:51:22 UTC