ISSUE-4 (html-versioning) (vs. ISSUE-30 longdesc)

(see end of message for motivation)

Look at http://www.wabcluster.org/uwem/tests/

"Tests for conformance evaluation" (which I found
by searching for 'longdesc' in 
http://www.standards-schmandards.com/projects/government-guidelines/ 

"This document is the result of a joint effort by 23 
 European organizations participating in three European
 projects combined in a cluster to develop a Unified Web 
 Evaluation Methodology (UWEM). It describes a methodology
 for evaluating conformance of Web sites with the W3C 
 Web Content Accessibility Guidelines 1.0."

The actual tests for conformance evaluation include
testing for whether  longdesc is there:

Test 1.1_HTML_04
This test is targeted to analyse long descriptions
of media elements.
 * Applicability criteria: all long descriptions
   of images and media elements. 
  //img/@longdesc
  //object//a/@href
 * Test procedure:
   1. Check that the long description referenced
      by the longdesc or href attribute is available.
   2. Check that it appropriately describes the element.
 * Expected results: FAIL if #1 or #2 is false.

of course, so is having a document grammar,
having a valid DOCTYPE declaration, and
being parsed as valid according to a validating
parser. So of course these tests will need to be
updated for HTML5, but how? 

David Singer had suggested (I think) that the
guidelines could be version specific. In that
case, the tests for "longdesc" could be version
specific -- test if "longdesc" is there for 
HTML4 documents, and something else for HTML5
documents.

I agree that doing so is somewhat uncomfortable -- it
would be better to have a methodology which tests
for sites doing "the best they can do", but having
a stable benchmark against which one can measure their
work is also important, isn't it? Would you want the
guidelines to tell each agency that wanted to be
conforming to test to check to see what the latest
W3C and WHATWG edition of the HTML spec recommends
each time they want to evaluate whether a web site
is or isn't accessible?

How else (if you don't use version indicators)
would you suggest that the UWEM tests be changed,
in order to allow them to adapt to evolving technology 
for accessibility while still remaining stable?

If not keying the accessibility method to the version
indicator, what else would you do?

I understand the problems version indicators have
caused in the past, and I wish they weren't necessary.
But there are use cases for which I can't think of any other
solution, and I think the harm that is ascribed to them
(of "reverse engineering costs" and "version-dependent
browser behavior") is better laid as the fault of other
factors, like allowing HTML interpreting agents to use
the version indicator as a guide to how the HTML is to
be interpreted.

Anyway, this seems like a use case which involves
two issues, ISSUE-4 and ISSUE-30. I think it's
a valid use case (at least to the members of the
committees that were trying to build test cases
to test accessibility against guidelines.)

In looking into this, it seemed like accessibility guidelines
actually do have an effect.


While commercial sites may informally want
to reach their largest constituency, government agencies
have a different "reach everyone" mandate, and these
kinds of guidelines have a role in promoting the social
good in a way that isn't always met merely by market
forces.

> Validators are just programs, they have no feelings,
> they won't get hurt ;-)

I'm not sure how this is relevant or helpful.
For some social goods, regulators want to publish
concrete guidelines for meeting additional
constraints and policies,  where the guidelines
are explicit but also adaptable as technology
changes. And, not only that, they want to automate
or at least explicitly describe a technique for
validating whether the guidelines are met.

UWEM seems to be an example of such a set of
guidelines and tests.

===============================================
Postscript: I was told

> It is still unclear what problem you are trying to 
> solve.

TAG issue 41 has been open a long time:
http://www.w3.org/2001/tag/group/track/issues/41

(Please note that the TAG uses the "RAISED BY"
field in the issue tracker as the "issue shepherd";
I didn't raise this issue, it was raised in 2003
and I only joined the TAG in 2009.)

It seemed like focusing the question on HTML5
would help address the general issue.
There is a long-standing TAG finding that languages
SHOULD have version indicators, and yet here is one 
(HTML5) that doesn't have, or want, one. How to 
reconcile these?

I don't have a personal stake in the outcome of this
issue,  except for the general desire to see the
web have a consistent architecture, and that HTML5 get
finished and deployed. If there are barriers to
adoption--e.g., if regulated sites have to stick with
HTML4 because there are no accessibility guidelines
that allow them to move to HTML5 and still be
both valid according the HTML5 spec and also
valid as far as meeting accessibility guidelines,
that would be bad for the web in general and
HTML5 in particular.

I had a change proposal being discussed for ISSUE-4;
there was a deadline to update it to note that it
also addressed ISSUE-84, but ISSUE-84 has already
been addressed (whether satisfactorily or not
I don't know) in the spec itself.

I'm hoping that "amicable resolution" might be
a possibility yet. I think I've found several
use cases where a "version indicator" is useful,
though, all around their use in content management.
The "laws, regulations, policy" situation is 
one which also impacts ISSUE-30 longdesc, and
so looking at these both would seem to be helpful.

(I suppose anything I write can be taken out of
context and tweeted and blogged about, which isn't
really helpful for an "open" discussion, alas.)

===================================

Larry
--
http://larry.masinter.net

-----Original Message-----
From: Jonas Sicking [mailto:jonas@sicking.cc] 
Sent: Friday, February 26, 2010 9:52 PM
To: Larry Masinter
Cc: Maciej Stachowiak; Adam Barth; David Singer; HTML WG; Charles
McCathieNevile
Subject: Re: Counter change-proposal for ISSUE-4 (html-versioning)
(vs. ISSUE-30 longdesc)

On Fri, Feb 26, 2010 at 9:03 PM, Larry Masinter <masinter@adobe.com>
wrote:
> In
http://lists.w3.org/Archives/Public/public-html/2010Feb/0750.html,
> David Singer <singer@apple.com> wrote, in a discussion of ISSUE-30
> longdesc, with respect to accessibility laws, regulations and
> organizational policies which might refer to a particular HTML
feature:
>
>> "More to the point, they [laws, regulations and policies] were
>> written with a particular version of HTML in mind and existence,
>> whether or not they remembered to say so.  The laws in question,
>> as I understand, were never intended to be prescriptive of what
>> standards-writers wrote, merely descriptive of what was in the
>> said standards (the laws are prescriptive in other respects,
>> of course).
>
>> When the HTML version changes, should they wish to adopt it
>> and prescribe how to use it, they are at liberty to do so."
>
> This raises the following question:
>
> What is a HTML version? Is there any way to distinguish one HTML
> version from another?

HTML 3 is defined here
http://www.w3.org/TR/REC-html32.html
HTML 4 is defined here
http://www.w3.org/TR/html401/
HTML 5 drafts are here
http://www.w3.org/TR/html5/

You can distinguish them by the title of the document :)

> What does "When the HTML version changes" mean ?

If I understand what David is trying to say, I would have phrased it
as "When a new version of HTML is released".

> How could someone write an 'accessibility regulation validator'
> if, as suggested, regulations might vary according to HTML version,
>  in the situation where HTML has no versions or version indicators?
>
> What happens if new accessibility methods are discovered in the
future?

My suggestion is to always recommend the latest and greatest when it
comes to accessibility. So for example, once ARIA is released and
supported by enough browsers, I would recommend content authors to
start using it. Even if HTML 4 remains unchanged and is the latest
released version of HTML.

I would not recommend anyone to recommend different techniques for
different versions of HTML. Why *not* ARIA for all documents if that
is what results in the best accessibility for users.

> In particular, if there is a regulation for which:
>   * if "longdesc" is recommended for HTML4
>   * something else is recommended for HTML5
>   * later, for some future evolution of HTML
>     yet something else is recommended
>    (as new accessibility techniques evolve)
> \
> ... how could a validator tell if the document presented had been
prepared
>    according to version-specific regulation, if there are no version
>    indicators?

I would make recommendations based on what results in the best
accessibility for users. Not based on what validators say. Validators
are just programs, they have no feelings, they won't get hurt ;-)

/ Jonas

Received on Sunday, 28 February 2010 02:08:12 UTC