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

Re: Long descriptions spec - a basic idea

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Fri, 21 Sep 2012 17:24:57 +0200
To: Sam Ruby <rubys@intertwingly.net>
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>, "Roy T. Fielding" <fielding@gbiv.com>
Message-ID: <20120921172457922254.a88963ee@xn--mlform-iua.no>
Sam Ruby, Fri, 21 Sep 2012 05:22:33 -0400:
> On 09/20/2012 10:34 PM, Leif Halvard Silli wrote:

> I'd recommend starting from deciding what problem you want to solve.

The current CP was my basis. But I'm personally open to other ideas.

> Roy Fielding recently presented[1] one view on what longdesc is meant to be:
>   enhancing the public record so that it better fits the needs of
>   those with assistive technologies, without changing the visual
>   representation for those who don't use AT.
> His view may or may not represent what the HTML WG or that A11y Task 
> Force intends to pursue, but the prescribed behavior in the Instate 
> longdesc change proposal goes well beyond what Roy described, and 
> does so in a way that has not gotten a warm reception by those that 
> develop a number of user agents.

Roy Fielding's perspective is definitely present in the agreed CP. Just 
think of the "no visual encumbrance" requirement. But we know that e.g. 
contextual menus are not very popular amongst many vendors. So may be 
the feature should be obligatory to AT but optional in browsers? But 
Apple has sounded like a bottleneck, regardless. Though, this, from 
James, was somewhat positive: [*]

> I will add it. I assume you mean something like this? 
> <img src="…" longdesc="#link"><a id="link" href="data.html">Foo</a>
> FWIW, I think that's probably a better implementation idea than the 
> current proposal for "DescribedAt":
> <img src="…" aria-describedat="#link"><a id="link" 
> href="data.html">Foo</a>
> rel="longdesc" or no? 
[*] http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0365

> Define something that is likely to be universally implemented by next 
> year, or define something that is explicitly NOT intended to be 
> universally implemented.  Or do both, perhaps on different schedules.
> Depending on which path you chose, different levels of validator 
> warnings may be appropriate, or no warning at all.
> Things with a universal appeal and are likely to be nearly 
> universally implemented in the near term stand a strong chance of 
> becoming integrated into the HTML5 specification.

Come with the ideas - whoever ...

> In yesterday's A11y telecon, Janina used the normally emotionally 
> charged term "ghetto", but did so to make a point: there actually are 
> advantages to a "ghetto" specification.  As this was near the end of 
> the telecon she did not have a full opportunity to explain what she 
> meant by that so I may be misunderstanding, but there is nothing 
> wrong with intentionally pursuing a "ghetto" specification, nor is 
> there anything wrong with intentionally pursuing integration into the 
> HTML5 specification.  You just may end up specifying different things 
> depending on what problem you want to solve.

If Microdata and HTML+RDFa are ghetto specs, then I agree that ghetto 
specs can work fine.

> - Sam Ruby
> [1] http://lists.w3.org/Archives/Public/public-html/2012Sep/0309.html

leif halvard silli
Received on Friday, 21 September 2012 15:25:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:31 UTC