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

On Thu, May 12, 2005 at 05:06:43PM -0400, Joe Clark wrote:
> 
> (Just the guideline and success criteria.)
> 
> Guideline 1.3
> 	Where permitted by the markup languages
> 	and technologies in use, ensure the separation of
> 	structure, presentation, and behaviour.

"Markup languages" are a subset of "technologies" under the current 
definition of "technology". Thus the phrase "markup languages" should be 
deleted from the above on grounds of redundancy.
> 
> 
> Level 1 success criteria
> 
> 	1. Structures within the document can be
> 	programmatically determined.

We resolved to accept this, for good reasons.

> 
> 	2. Structural markup or coding is used to encode
> 	semantics to the extent possible for the content.

This should be deleted for various reasons, as follows. 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. Requiring that "semantics" be encoded as far as 
possible for the content is extremely onorous. 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.

Nor should WCAG seek to narrow or redefine the meaning of the term 
"semantics", which has had a widely accepted usage for a very long time 
as pertaining to the meaning (sense, reference, intension, extension, 
etc.) of the expressions of a language, whether it be a natural language 
or a formal language such as a markup language. The meaning of 
"semantics" is the same whether applied to a natural language, a 
language defined in formal logic (classical, modal, multivalued, 
paraconsistent or whatever), or a markup language. We should not be 
attempting to narrow or redefine the term.

> 
> 	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; nor 
is an API that provides role/state information.
<propose>
Information presented through colour can also be programmatically 
identified.
</propose>
If you want to add labelling in for some reason (I don't think it is 
necessary) the proposal can be modified accordingly.

> 
> 	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. Suppose the technology does not have an 
authoritative specification, or has one that doesn't mention 
accessibility; there is no reliable way of determining which to count as 
the "accessibility" features. Worse, I can't think of a good example in 
which this wouldn't be redundant with the remainder of 1.3, especially 
after "programmatically determined" has been defined along the lines 
that we have in mind. This proposed success criterion should be deleted.

> 
> 
> Level 2 success criterion
> 
> 	Only markup languages and technologies that enable
> 	separation of structure, presentation, and behaviour are
> 	used.

"Markup languages" should be deleted for redundancy, as above. This 
whole proposal is untestable: what degree of separation is sufficient to 
satisfy the proposal, how can this possibly be evaluated, and how does 
this add anything to the requirements of level 1? 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.

The success criterion related to label, role, state and value emerging 
from the guideline 4.2 discussion is absent from this proposal, but 
should be included in any proposal considered for adoption as the 
revised text of 1.3.

Received on Friday, 13 May 2005 05:49:29 UTC