Re: Speech browser compatibility with HTML

From: "Phill Jenkins" <pjenkins@us.ibm.com>
Subject: Re: Speech browser compatibility with HTML

[Using IBM's Homepage Reader]

Thanks for the guidance about tables mode and text mode. Its a gross
assumption on my part that's the source of my misunderstanding. I've now got
a copy of HPR installed and tried out a few pages - mostly from the BBC -
with screen blacked out (well covered with an Amazon cardboard envelope
which fits my laptop screen almost perfectly).  Its hit me hard by how
powerful and useful screen readers can be - and how the littlest of things
(like not using alt attributes) makes even the simplest thing of checking my
amazon shopping basket close to impossible (I tried buying a book via
amazon.co.uk entirely using a speech browser - no alt attributes on images
and "munged" URLs, and I even knew whereabouts the basket icon was, and I
still couldn't find it in a speech browser!).

Previously - the example that initiated this particular thread - we had a
demonstration from an external consultancy. A fully sighted user, and he
didn't invoke the tables mode (the assumption I made was that he knew how to
use the speech browser to navigate tables). This is a good example why
speech browser testing by fully sighted users is flawed - in that we first
need to understand how the product works otherwise we'll end up working
around "problems" that don't really exist - like the "lack of support for
scope".

Consider me egg-on-faced :-)

[In regards to P W D L GF table headers]
> Whether the use of the title attribute is better or worse
> than the ABBR element remains to be investigated.

Since you mention the title attribute won't override the actual text in the
header (by default in table data-navigation mode), then ABBR would be a more
logical alternative, since they are just that - abbreviations.


> But it doesn't make
> sense to me to have the sighted user see the headings: P W D L GF etc. and
> then expect the screen reader to automatically read something different.
> In other words, why should it read the title attribute over the actual
text
> of the heading?  That would be like turning all tool tips on all the time
> for a sighted user.  Who would want that?

Only someone new to the typical league table format. Within the UK most
football-mad people know what the abbreviated headers mean. So the
additional information and unwinding of these headers is only needed for the
occasional lapsed memory, or someone encountering a league table for the
first time. I don't recall ever seeing this sort of table published with the
full "Games Played", "Games Won", "Games Drawn" - it is _that_ "inbred" into
UK culture.

The problem/opportunity I haven't resolved yet is to allow the meanings of
the abbreviated form to be accessible. At the moment in a speech browser I'd
like it to say just "Played", "Won", "Drawn", "Lost" as the title when
entering the relevant table cell data (for pure listenability more than
anything else) - would I have to revert to making those the actual table
headers?

Is there a clean structured way of displaying it onscreen as P W D L GF
(with or without tooltips), while a screen reader could (at the option of
the user is fine) read "Played" "Won" "Drawn"? I'm starting to think that an
explanation page is perhaps the way to go, especially on sites that make
continual use of this particular table structure, rather than describing on
each occurrance what the table means.


> I don't know of any side-by-side comparisons like the CSS example, but
> there is an excellent comparison of HPR's support of the W3C's User Agent
> Accessibility Guidelines at the "Summary Implementation Report for UAAG
> 1.0" (see http://www.w3.org/WAI/UA/impl-pr2/)

Thanks for the link - its an excellent grounding/overview of support. (I've
not read much about the UAAG - so now is a good time as ever).

Mike.

Received on Saturday, 30 August 2003 07:11:31 UTC