[Fwd: Re: [gcs-pcs-list] Re: Revisiting the choice of <abbr> for unAPI?]
Alf Eaton
Subject: Re: [gcs-pcs-list] Re: Revisiting the choice of <abbr> for unAPI?
Date: Mon, 12 Nov 2007 19:44:47 +0000 (GMT)
From: Barry McMullin <barry.m...@dcu.ie>
To: Alf Eaton <a...@hubmed.org>
CC: Barry McMullin <barry.m...@dcu.ie>
References: <1194448176.0...@57g2000hsv.googlegroups.com> <4731E3BC...@hubmed.org> <Pine.LNX.4.58.07...@pompeii.eeng.dcu.ie> <47387D4C...@hubmed.org>
On Mon, 12 Nov 2007, Alf Eaton wrote:
> Do you know if there's an attribute (a class, maybe) one could
> add to <abbr> elements to say to screen readers "don't read the
> title of this element"?
Hi Alf -
To my knowledge, there is nothing quite as simple as that...
However, in theory at least, a site using unAPI *could* play with
CSS styling, and try setting the relevant ABBR elements to
"display: none", which *ought* to suppress all "display",
including speech output (even of the title attribute). (Actually
there is some debate about whether this *should* suppress speech
output; but the practical reality seems to be that it usually
does.)
This is a practical strategy in the specific case of unAPI (in
contrast to some other microformats using ABBR) because, with
unAPI, the ABBR has no "real" content to be rendered, so no harm
is done by potentiallly supressing its display with the display
property. Mind you, screen readers are commonly
idiosyncratic in handling CSS in general and "display" in
particular; and indeed, browsers and assistive technology in
generally are expressly permitted to override or ignore all
author supplied styling. So a CSS approach to this cannot be
fully reliable, and could not technically satisfy accessibility
guidelines (i.e., WCAG 1.0, checkpoint 6.1).
That said, I can't see immediately that there is any *practical*
downside to it, and it would *probably* help, so it could be a
step in a better direction. There would still be some choice in
implementation here (e.g. using class vs style attributes), but
these should be essentially interchangable from an accessibility
viewpoint.
Best - Barry.
--
Barry McMullin, Dublin City University
phone: +353-1-700-5432
web: http://www.eeng.dcu.ie/~mcmullin/
Alf Eaton
Subject: Re: [gcs-pcs-list] Re: Revisiting the choice of <abbr> for unAPI?
Date: Tue, 13 Nov 2007 10:08:28 +0000 (GMT)
From: Barry McMullin <barry.m...@dcu.ie>
To: Alf Eaton <a...@hubmed.org>
CC: Barry McMullin <barry.m...@dcu.ie>
On Tue, 13 Nov 2007, Alf Eaton wrote:
> It would probably be worth adding this as a recommendation to
> unAPI.
> I had read something recently (for a different
> purpose). I think the recommendation was to set both display:
> none and visibility: hidden.
Yes, that is also suggested. It seems it's really only necessary
in the specific case of A elements (and even then only for users
of the JAWS screenreader); but again, in the unAPI context, it
seems it can't do any harm and just may do some good. (From a
"theoretical" CSS point of view, I don't think it makes any
difference - visibility should be irrelevant once you have
"display: none".)
Ironically, much of the discussion of this issue out there is
concerned with the "opposite" problem to the one we are
discussing - where what is desired is actually to persuade a
screenreader to render something even though it is invisible,
rather then trying to suppress it, as we want; but it's all a
quite complicated story, and not really relevant to unAPI anyway.