RE: Screen-reader behaviour

At 23:08 -0700 UTC, on 2007-09-03, John Foliot wrote:

Thanks John, this was informative. (It also raises new questions ;))

> Sander Tekelenburg wrote:
>>
>> Why? Why would a HTML UA be unwilling to contribute to HTML5?
>
> Screen Reading technology is not HTML specific: Adaptive Technologies such
> as JAWS and WindowEyes (to name only two of a larger number of similar
> tools) work as "bridges" between specific OS'es and applications that work
> on those OS'es.

I understand. But I'm not thinking about screen readers only.

Btw, I do understand that people use tools like Jaws because they need to use
not just the Web, but other apps as well. But as I understand it there are
'stand alone' speaking (and braille?) browsers that work much better, no
doubt because they can focus on a single task. So I wonder why a Jaws user
does not use such a dedicated aural UA for his Web access? Is it too
complicated to learn to use both tools? Is it too expensive to buy both? Does
using both generate conflicts, or crashes?

[...]

> So, while there might be a peripheral
> need to follow what is happening with the mark-up language, the developers
> are most likely more interested in how the various UAs interpret the
> language.

OK, if the development of HTML itself isn't interesting to them, that's fine.
Perfectly legit. (I do hope that they are sure about this though; that they
won't suddenly, after HTML5 is "real world", realize that it makes their work
harder.)

For the HTML WG group that would mean then that those specific questions we
have are apparently not really important to us either.

(Then again, Chaals' explanation was that "dealing with this group is
expensive", which does not suggest it is unnecessary.)

[...]

>> I am not blaming Jaws. I said that Jaws looks worse than I even
>> thought, and that I very much want to know *why* that is; what
>> obstacles developers of such tools run into, so that we can start to
>> try to remove such obstacles from HTML5.
>
> There are a number of issues.  One, the development community that produces
> these tools is considerably smaller than those that produce the mainstream
> web UAs.  Smaller means slower (this sadly is also a 'market forces'
> situation).

Understood, but that's not a technical obstacle (in the sense that relates
directly to HTML5).

What you say below is another real problem of course, but also not a
technical obstacle for developers:

> There is also a cost factor, unlike the mainstream browsers
> (which are all free), software such as JAWS can cost upwards of $1,000.00
> USD - a considerable amount of money for any, and often an even larger
> burden for the very users who require it most, given that often they are
> living much closer to the poverty line.  For this reason, upgrading this
> type of software is much slower... I know of at least 2 daily-users today
> who are using a versions of JAWS that is 2 iterations behind the current
> release, simply due to this cost factor.

Well, worse, a newer version of Jaws no doubt will often require a newer
version of Windows, in turn requiring newer hardware (potentially including
dynamic braille devices, voice synths, etc.).

I wonder if this market might be changing though:

Without meaning to go into an advocacy debate about specific
vendors/qualities, I do wonder if something like Voice Over, assuming in Mac
OS X 10.5 it will be as improved as Apple claims, will do good here. You get
that 'for free' with the OS (which so far has cost $129,-). I realise that it
takes an effort to get used to different conventions, and that for for
instance a blind user it probably takes an even greater effort. But after
making such a change, it'd likely be much cheaper to keep things up to date.
Not to mention that with everything being integrated in the OS itself things
are much more likely to be stable, consistent, non-conflicting.

I believe we have one HTML WG member, David Poehlman, who made that switch.
Perhaps he can say something about this. How expensive, how hard is that
switch? Does it seem likely that more people will make that switch? Does it
seem likely that Voice Over will trigger the AT market into becoming more
competitive, products cheaper, quality higher?

Similarly, how likely is Linux to affect this? It is generally harder for Joe
Average to use, but also a lot cheaper. And the effort to provide (free) "AT"
for it appears to be growing.

Relevance: if we have strong evidence that people will stick with Jaws, we
know that what we decide for HTML5 will affect them for even longer than if
we have evidence that this market is changing and that in the coming years
users will be likely to use more up to date technology (because it becomes
more affordable).

> Finally, it appears that there is a bit of a "chicken and egg" situation
> going on:  it seems that prior to the latest version of JAWS, pages that
> included the LONGDESC attribute would "behave badly" (in some instances even
> crash the computer), forcing some agencies to actually (sadly) tell authors
> to *not* use this potentially useful attribute.

That's one of those things that I can't understand. How can such a fatal bug
remain in existence, across many (eight?) versions, for so many years? (I
could understand if it existed in Windows, or IE, or Windows' accessibility
API, but since you say it is fixed in the latest version of Jaws itself...)

[...]

> Thus one of the biggest obstacles is not the language itself, but rather
> adoption and implementation.

Right. So in that respect, what the HTML WG can do for "accessibility" is to
try hard to make sure that HTML5 is defined such that it is more likely to be
adopted (correctly) by authors than HTML 4, and describes UA implementation
in more detail, aiming to achieve better interoperability. It seems to me
that the current draft does pretty well on both those counts. (Yeah, I know
about the currently missing @headers, @summary, etc.)

> This, and remembering that the markup language
> is *supposed* to be an agnostic semantic tool, and not a visualization and
> rendering language.

Which the current draft states stronger than HTML4, by introducing <section>,
<figure>, etc. (OTOH, it currently tries to make exceptions for 'WYSIWYG
editor' output.)

Btw, a nagging gut feeling that I keep having with screen readers is that in
fact their very nature confirms the idea that authors should cater for
screens... As an author I can provide all the aural or braille CSS I want; I
can suggest things to be presented such that it is more useful when accessed
non-visually, but the damned screen reader will just stupidly try to convey
to the user what is presented visually :(

>> So I was in fact asking *who/what is to blame*. If we don't know what
>> the problems are, how can we fix them?
>
> It would be easy, and partially true as well, to say that much of the blame
> rests with development tools that focus on visual rendering almost
> exclusively.

Right. I'm working on a project to try to improve that situation (see URL in
sig). But I think the only thing that can be done about that within the HTML
WG is to try to make HTML such that authors no longer feel the need to abuse
elements; that HTML5 gives them what they wanted, in a way that works for
"accessibility". Stating that @alt and @title must be presented differently
is a concrete example. We don't yet seem to have a solution for <table> abuse
though and there appears to be plenty of disagreement still over how <i> is
to equal <em>.

[...]

> That sites such as Flickr
> and other photo-sharing sites do not allow contributors to add appropriate
> alternative text (never mind actually taking the responsibility to try and
> explain alt text to their clients) cannot be laid at the feet of the markup
> code, but rather at the feet of the developers and businesses themselves.

Well, up to a point. We can also blame UA vendors for making it non-obvious
how a webpage might 'look' when the author's alt text is presented instead of
the image. Merely allowing authors to author @alt doesn't mean they'll
actually do so, let alone do so in a useful way. Frankly I would not be
surprised if such a photo sharing site would become even less usable, through
massive incorrect use of @alt.

This is one of the reasons why the proposed <alt> element seems interesting
-- it could be 'less invisible' to authors and thus likely easier to use
correctly.

> [...] "Web 2.0" conference in San
> Francisco (Silicon Valley). [...]
> "...addressed in the next release" (I almost cried).  With this kind of
> apathetic response rampant at a trade show that is/was supposed to be
> showcasing the latest and newest of/on the web, is it any wonder that the
> accessibility community cringes at any suggestion to ease off one inch (like
> suggesting that alt text be made optional, or abandoning LONGDESC)?

I fully understand the frustration, but let's not mix up sales bots with
argumented proposals to improve HTML. I'm not convinced yet myself that
making @alt optional is the right way to go, but the idea is based on an
argument that does seem sensible: some images are purely decorative, others
are not yet have no (useful) textual equivalent -- can we cater for that
distinction, to improve users' experience of the Web?

[...]

> I don't know what the answer is to this problem (actually it's education),

Maybe, up to a point. For myself I've, after many years of
education/advocacy, more or less concluded that education isn't going to get
us very much further. Improving authoring tools, and reconstructing HTML such
that it becomes easier for authors to produce accessible content, seem to be
roads that can make a *much* bigger dent.

Don't get me wrong, education is useful and I agree that we must give people
time to learn how to author for the Web. Just because an element or attribute
is used wrong is in itself not enough reason to trash it. But when such wrong
use can be fixed by replacing the element/attribute with something for which
there is good reason to expect that it will be used much better, then we
should be open to that.


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Tuesday, 4 September 2007 18:22:29 UTC