W3C home > Mailing lists > Public > wai-xtech@w3.org > July 2007

Re: conflation of issues or convergence of interests?

From: Patrick H. Lauke <redux@splintered.co.uk>
Date: Sat, 28 Jul 2007 13:47:20 +0100
Message-ID: <46AB3AD8.8070901@splintered.co.uk>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
CC: public-html@w3.org, wai-xtech@w3.org

Lachlan Hunt wrote:

> I don't understand that reason.  In particular, "while presenting only a 
> single link to the user interface" doesn't make sense.  Where and how 
> are you imagining the UA to present this single link?

In place of the video, if the user has chosen to so configure the UA 
(either manually, or in conjunction with a combined CC/PP and ACCLIP 
http://www.imsglobal.org/accessibility/#acclip profile).

> There is no requirement for all accessibility features to be testable 
> using automated accessibility testing.  Such a requirement would only 
> place arbitrary restrictions upon the development of accessibility 
> features, limited by the abilities of testing tools.  Accessibility 
> features should be evaluated according to how well they benefit users, 
> not how easily a tool can test for it.

Agreed, but user agents need to, imho, also be able to make sense of the 
markup/content associations, so they can let the end user know that 
they're not missing out on any content just because they can't render 
the video, for instance.

> Possibly, but that would need research to determine things like whether 
> users actually want or need that feature, whether or not they would 
> really use it if it were available, and whether UAs, especially 
> assistive technology, could or would implement it.

And, going back to the usual argument, we'd need user research to 
determine if NOT providing the suggested association would harm or 
inconvenience the users.

Also, I find it quaint that you have the "whether UAs could or would 
implement it" there. Is this sort of rigorous research also applied to 
all the other decisions that have been made up to now (cowpaths and all) 
with regards to HTML5?

> BTW, there was a suggestion for <a rel="longdesc"> a while ago, which, 
> when used within <figure> and <legend>, is a possible solution.

I'd love to see a more direct relationship, maybe along the lines of how 
<label for="#IDREF"> works for form element labels.

> No, the user is the whole point.  If it can be conclusively shown that 
> the user is somehow disadvantaged because their UA doesn't provide some 
> special functionality, then we can look at addressing those problems for 
> the user.  But simply assuming that the UA needs to do something special 
> and then jumping to the conclusion that we need to provide for that 
> doesn't help.

And vice-versa. Also, I believe that the core idea here of user agents 
doing "something special" is firmly based on how they currently already 
handle <img alt="..."> (where screen readers, for instance, "do 
something special" in terms of reading out the ALT, rather than simply 
saying "here's some image, full stop", and based on the way that 
<object></object> fallback content is rendered in situations where the 
UA is unable - either through missing plugin/handler or through user 
preference - to render the object itself).

> I'd like to see some user testing of this issue, and some documentation 
> of existing video sites and their accessibility features.  Are there any 
> existing video sites that provide textual alternatives for videos?  If 
> so, we can look at how they do it and, through user testing, evaluate 
> how successful their approach is.

Just wondering (as usual again) why, if we're working on a new set of 
language building blocks, we need to look at current practices that use 
the limited vocabulary available today...whatever sites currently do is 
obviously related to how HTML4/XHTML1.x handles video and such. Why 
should that inform how this new and improved language should handle it 
as well? But yeh, let's go along with that...

Patrick H. Lauke
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
Co-lead, Web Standards Project (WaSP) Accessibility Task Force
Take it to the streets ... join the WaSP Street Team
Received on Saturday, 28 July 2007 12:47:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:51:33 UTC