Re: conflation of issues or convergence of interests?

Patrick H. Lauke wrote:
> 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

OK.  That seems like it could be a bit redundant if the link is already 
available elsewhere on the page, though perhaps there is some benefit 
gained from the convenience of it being there.

>> 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.

That seems to mean the same thing as "whether users actually want or 
*need* that feature", but said in a different way.  Obviously, if there 
was harm or inconvenience, then would be a need for the feature.  So, 
agreed!

> 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?

Of course!  Implementation feedback is vital to the success of HTML5. 
There have been lots of things that have been added, changed or removed 
based on implementation feedback, and it's entirely possible that some 
feature in the spec today will be changed or removed in the future based 
on such feedback.

The question of whether or not they could or would implement depends on 
a whole range of factors, including market demand, cost and complexity 
of implementation, etc.

>> 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.

Agreed.

>> 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...

Because looking at current sites lets us see how the problems we are 
trying to address are currently being solved using the available tools, 
and seeing exactly where the limitations really are.  It also gives us a 
good starting point for any possible solutions, since we can build on 
what is already being done, instead of inventing something completely new.

In another post, you wrote:
> As was noted before, even if a large percentage of sites/authors here
> and now don't take advantage of an HTML 4 language feature, that
> doesn't necessarily mean that the feature should be scrapped...but I
> guess that's really the crux of this argument.

This has probably been noted before also, but if a feature doesn't get 
used, then it indicates that it probably wasn't well designed.  For 
instance:

* It may not really solve the problem, in which case other, more
   successful solutions, may have developed and should be investigated.
* There may be little practical incentive for authors to use it.
* It may be quite difficult or require too much effort to use.
* It may have been really poorly implemented, if at all, in which case
   there may be serious technical issues or a lack of market demand.

I agree that those reasons don't necessarily mean that a feature should 
be scrapped, but it should definitely be heavily scrutinised, with a lot 
of effort focussing on how to either improve it or replace it with a 
more successful solution.

-- 
Lachlan Hunt
http://lachy.id.au/

Received on Saturday, 28 July 2007 14:11:01 UTC