RE: Bare-bones proposal for 1.3, "Ensure that information, functionality, and structure are separable from presentation" (re-send)

Just one small piece of the exchange between Joe and Jason. 

Jason writes:
.... For example, tagged PDF is not a markup language...

Joe responds:
In a strict sense, *possibly*. Nonetheless, it adds structure.

But tagged PDF "adds structure" in a different way than, say HTML or XML
markup "add structure." I was told just yesterday, in fact, that the PDF
tags remain entirely separate from the document-- to such an extent, in
fact, that edits to the document are not reflected in the tags.  (For
example, a block of 5 or more pages was deleted from somewhere in the
document; the corresponding tags were not deleted, however, so had to be
removed manually.

(Loretta, if I'm misrepresenting the relationship between the tags and
the document please correct me!)

John



"Good design is accessible design."

Dr. John M. Slatin, Director 
Accessibility Institute
University of Texas at Austin 
FAC 248C 
1 University Station G9600 
Austin, TX 78712 
ph 512-495-4288, fax 512-495-4524 
email jslatin@mail.utexas.edu 
Web http://www.utexas.edu/research/accessibility 



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Joe Clark
Sent: Friday, May 13, 2005 10:55 AM
To: WAI-GL
Subject: Re: Bare-bones proposal for 1.3, "Ensure that information,
functionality, and structure are separable from presentation" (re-send)



> In so far as it requires structure to be programmatically 
> determinable,
> and technologies (including of course markup languages) to be used 
> according to specification, it is redundant due to guideline 1.3 sc1
and 
> guideline 4.1 respectively.

The redundancy is in dispute. The harm of being redundant is arguably 
lower than the harm of leaving it out.

> Requiring that "semantics" be encoded as far as possible for the 
> content
> is extremely onerous. It would demand among other things that a 
> symbolic, formal language be used to express the content instead of a 
> natural language wherever feasible, which is hardly warranted at level

> 1.

False. See below. You're simply misunderstanding the sense of the term 
"semantics."

> Nor should WCAG seek to narrow or redefine the meaning of the term 
> "semantics,"

While the WCAG Working Group was doing other things, leaders and
pioneers 
in the field of Web standards added a sense to that term. I am aware
that 
many Working Group members find it odd to discuss "document semantics"
in 
this context, but everyone involved in Web standards finds it no big
deal. 
Whether you are aware of it or not, you *are* working in the field of
Web 
standards and, as I have explained before, if you want people to work at

your level you have to work at theirs.

In short, the world has changed and WCAG WG needs to adapt.

> We should not be attempting to narrow or redefine the term.

You wouldn't be. It's already happened.

>> 	3. Information presented through colour is also
>> 	available through markup, labelling, or both.
>
> This wording assumes that a markup language is being used, which is 
> not always the case. For example, tagged PDF is not a markup language;

In a strict sense, *possibly*. Nonetheless, it adds structure.

> <propose>
> Information presented through colour can also be programmatically 
> identified. </propose>

I think that's as clear as mud and is about as helpful as the oldschool 
WCAG WG guidelines. My wording is actually understandable and does not 
fail to achieve technological neutrality, as impled.

>> 	4. Markup or coding for presentation or behaviour uses
>> 	accessibility features available in the technologies
>> 	being used.
>
> The main problem with this is that it fails to identify what the 
> "accessibility features" are.

That's why we have techniques. You realize we do this already for 
WCAG 1.0, I trust?

> Suppose the technology does not have an authoritative specification,

Three examples, please?

> Worse, I can't think of a good example in which this wouldn't be
> redundant with the remainder of 1.3,

Well, how 'bout the fact that e.g. tabindex and accesskey are strictly 
optional attributes *according to spec* and are also *not semantic*?

Leave this one out and there is no requirement whatsoever to use those, 
for example.

As I explained twice already, that success criterion was added to cover 
unstructured document formats like Flash that nonetheless have 
accessibility features. Can't use structure? OK, we'll live with that.
But 
you *must* design for accessibility.

> This whole proposal is untestable:

It's perfectly testable. You run the page through the validator. You
then 
use human testing to examine the source code (in [X]HTML) or tags (in 
PDF), to give two examples. If every single object on the page is a div
or 
a span, you flunk the criterion. If you're using headings, paragraphs, 
lists, and the like, according to the *document semantics*, you pass.

I could put ten of my standardista friends together and the required 8
or 
8.5 of them would agree on the assessment of any given page.

In fact, we can try that. Somebody give me three real-world pages to 
test-- pages unrelated to anyone in the W3C. I'll get my friends to 
evaluate them and I'll post to the list. Then you'll have actual data.

> If structure and behaviour-relevant details such as role and state can
> be programmatically determined, surely taht should suffice and there
is 
> nothing extra to be accomplished here that helps accessibility.

Oh?

What if I mark up everything in my document as a paragraph? How does
that 
not harm accessibility?

I am aware that Web standards are unfamiliar to many Working Group 
members, despite the fact they are actually writing a standard, but I 
would request doing a bit of homework before dismissing established 
concepts like these.

-- 

     Joe Clark | joeclark@joeclark.org
     Accessibility <http://joeclark.org/access/>
       --This.
       --What's wrong with top-posting?

Received on Friday, 13 May 2005 22:27:03 UTC