- From: Isofarro <w3evangelism@faqportal.uklinux.net>
- Date: Sat, 30 Aug 2003 12:11:45 +0100
- To: <w3c-wai-ig@w3.org>, "Phill Jenkins" <pjenkins@us.ibm.com>
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