W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2012

RE: 48-Hour Consensus Call: InstateLongdesc CP Update

From: John Foliot <john@foliot.ca>
Date: Mon, 24 Sep 2012 22:22:47 -0700
To: "'Maciej Stachowiak'" <mjs@apple.com>, "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>
Cc: "'David Singer'" <singer@apple.com>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
Message-ID: <008201cd9add$cefefe00$6cfcfa00$@ca>
Maciej Stachowiak wrote
> 
> It does seem to me like the little (i) in a circle is reinventing d-
> links, and I thought the whole original reason for longdesc's existence
> was that content authors found the visual encumbrance  of d-links
> unacceptable.

Yes, but this is and was a PoC to show how @longdesc content could be
exposed without leaving the current page, and without a visible trigger it
could not be shown.

> In fact, the InstateLongdesc Change Proposal explicitly
> states that lack of visual encumbrance in the normal presentation is
> required.

Yep, the key word here being "normal".  I've just answered Silvia about this
very item, so I will avoid repeating it here, except to re-enforce that by
making this a browser setting (as opposed to something that the author needs
to do) that we can in fact have our cake and eat it too.

In fact, it was just this point that I made to both Steve Faulkner and Rich
Schwerdtfeger almost 2 years ago that got them more on board with preserving
@longdesc.
(http://www.brucelawson.co.uk/2011/longdesc-in-html5/#comment-749840) 


> I find myself confused at the promotion of a browser-imposed
> visual encumbrance for longdesc.

It would be a browser-provided visual encumbrance, set via the user
preferences. 

I can set my browser to advise every time it attempts to accept an SSL
(secure link), I can over-ride author style sheets wholly, or simply by
prescribing a specific minimum font size. I can sett various level of
acceptance for cookies, and generally I can fine-tune my browser to best
meet my personal needs. Like most users, I tune my rig to meet my needs and
then generally leave it at that. For those sighted users who want to be
advised when longer textual descriptions are available, they'd set it and
forget it, and accept that minor visual additions to the authored page as
something *they* chose to see. Further, as a browser offering, it would be
standardized (at least to any specific browser), at which point I could also
start to visually filter it out (mentally speaking - like ignoring banner
ads), and only "notice" them when I needed to.

> If it is acceptable, then the author
> could overlay a visible link looking like the ittle (i) in a circle,
> reference it with aria-describedby, and be done.
> Am I misunderstanding
> some aspect of this discussion?

The debate over whether ARIA is only for mapping existing UI controls to the
AAPI (David Bolter) versus the browsers should do more with ARIA (Chaals),
for one...

JF
Received on Tuesday, 25 September 2012 05:24:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 25 September 2012 05:24:16 GMT