Re: Organizing WCAG 2.0

At 11:28 AM +1000 8/19/00, Jason White wrote:
>a. Can the creator of the markup language (or of the extension) claim
>conformance? Under Ian's proposal, the former presumably could not,
>whereas the latter may be able to do so, depending upon the nature of the
>conformance definition in the technology-specific profile.

I don't think we are defining meta-accessibility; it seems to me
that we have our task cut out for us with just plain accessibility.

In other words, I think that Markup Language Accessibility
Guidelines (MLAG) are another related activity just as Authoring
Tool Accessibility Guidelines are a separate document.  I think
there are enough issues unique to markup language creation and
a different enough audience that trying to force WCAG to have
too many "uses" will make this too complex.

(Of course, there can be interdependencies between WCAG and
MLAG, just as there are between WCAG and ATAG.)

>b. Can a content developer who deploys the new markup language (or the
>extension, as the case may be) assert conformance? Again, in the former
>case, presumably not, whilst in the latter it would depend on the
>technology-specific conformance definition, the nature of the extension
>and its usage.

I guess you are asking "if conformance is based on what we've
written as specific checkpoints, and nobody has written specific
checkpoints to cover this case, can conformance be claimed?"
I think the answer to this is self-evident but also a result
of the very process we're talking about.  I don't see if there's
any reasonable way to get around this, in other words, nor do I
see it as necessarily desirable to do so.

>Needless to say, if the technology-specific profiles are required to
>become W3C Recommendations, then the requirements of W3C process can
>readily introduce a significant lapse of time between the appearance of a
>new technology and the derivation of a relevant profile.

I'm not sure if that's the case here, but even if it is, I'm not
sure if that's undesirable either.  Usually for new W3C-approved
technologies, we have sufficient lead time (from public drafts
being released, P&F working group, etc) to at least consider the
issues of accessibility, especially if we (WAI) maintain contact
with people doing example implementations.

>If new markup
>languages and, as is more likely, extensions of existing formats become
>numerous it will become increasingly infeasible for a body such as the W3C
>to develop technology-specific profiles which accommodate all of them.

But it also will become harder to produce a nice "generic" document
that covers all categories, and which -- by nature of being
inspecific -- may allow people to claim accessibility inherent
in their products by assertion when in truth they have little to
support their claims.  A relatively vague set of "principles"
would allow a technology vendor to proudly display the "WCAG
approved" (or MLAG approved) banner without having met any specific
technical checkpoints.

<sarcasm>
Of course, no vendors would ever claim accessibility and standards
adherence without being able to prove it!
</sarcasm>

>Before concluding, I would like to put forward a proposal which strives to
>meet these objections.
>
>1. The generalized guidelines (comprising the technology-neutral layers as
>Ian suggested) would have conformance criteria, but only software
>protocols and data formats could (directly) conform. Thus, an entity which
>developed a new technology could assert compliance, thereby claiming that
>the technology includes features which, if used correctly, would satisfy
>the requirements of the guidelines.

This sounds like MLAG.  Yes or no?  If this is part of what we're
setting out to do, I strongly recommend that we go through WAI
coordination group and consider the possibility of making this a
separate activity.

>2. The W3C would create technology-specific profiles as Recommendations.
>In the absence of a profile relative to a particular technology or
>extension thereof, content developers could rely on any usage guidelines
>promulgated by the developer of the new technology (or extension), though
>the latter would not have the force of a W3C Recommendation. Perhaps the
>developers of new technologies could be encouraged to take advantage of
>the W3C submission process to propose technology-specific profiles for
>consideration, and possible adoption, by the relevant working group.

Well, I'm okay with this suggestion.  Thought I'd argue with
everything, eh? :)

>One consequence of these arrangements would be the ongoing need for a
>working group, constituted similarly to the Web Content Guidelines group,
>to oversee the ongoing development of technology-specific profiles, qute
>apart from any revision of the guidelines that might ultimately be needed.

I see it the other way around; I see WCAG remaining the group dealing
with content and authoring, and MLAG being the one that's up a meta
level.  I think we have too many references out there which say
"refer to WCAG" and if WCAG suddenly became a different document,
this would be a serious problem in terms of practicality and usability.

It's one thing to say "use our version 2.0 now", it's another thing
to say "well, we changed what WCAG is about and now we want you to
use a completely different document, oh yeah, and you probably won't
understand WCAG now unless you're writing markup languages."  We very
much risk the kind of "give up in disgust and frustration" scenario
which Gregg described, and so for practical reasons I think it makes
more sense to keep WCAG as what they've been advertised as extensively
in the media, in policy documents, in tutorials, and in congressional
hearings.

>I hope these arguments are sufficiently clear and that I have satisfied
>most of the pertinent requirements.

I think we're all going about the same place on this; I suspect that
most of our differences deal with terminology, perspective and
practicality rather than with philosophy or procedure.

--Kynn
-- 
--
Kynn Bartlett <kynn@idyllmtn.com>
http://www.kynn.com/

Received on Sunday, 20 August 2000 18:26:08 UTC