Reasons to move validity back to P1

Firstly, thank you to Gregg and John for allowing me to put forward my
views on validity. I've listed the working group's rationale for
moving validity to priority 2, preceded with WG:. My responses are
preceded with GL:.

WG:
That well formedness and validity can benefit accessibility. However,
forcing strict adherence to the specification can sometimes inhibit
accessibility.

GL:
I fail to see how strict adherence inhibits accessibility. I assume
this has come from the DHTML roadmap, where Becky's put forward an
argument about not being able to use custom attributes. The simple
solution is to use XHTML 1.1, and define the attributes, as that's
what modular XHTML was meant for. I've read the counter-arguments that
XHTML 1.1 "should not" [1] be served as application/xhtml+xml, and
that all the time IE is the most dominant browser, that's not a
feasible solution. I strongly advocate serving any version of XHTML as
application/xhtml+xml, but in this particular case, I would think it
was a lesser evil to deliver the content as text/html all the time
that IE doesn't support the correct MIME type. The reason IE is in the
powerful position it is is because everyone panders to it. It's a
broken browser that can only handle text/html, so let it have
text/html. Delivering XHTML as text/html definitely does not cause any
accessibility problems. Delivering invalid content *may* cause
accessibility problems. If none of that is acceptable, there's always
the get out clause.

WG:
(Also, validity of any declared specification in and of itself doesn't
guarantee accessibility because you could create your own
specification and be valid to it.)

GL:
I also fail to see why this is a problem. If someone creates a custom
DTD, you'll at least know the content is well-formed. This clause
implies that the working group do not agree with modular XHTML.
Modular XHTML is a great idea, as it does allow developers to add
features that are not part of a public specification and remain valid.
Someone could create a custom DTD and change the alt attribute to
optional rather than required, but that's covered by another
guideline. Any harm that could be done by creating a custom DTD should
be covered by other guidelines, as the guidelines are meant to be
broad enough to deal with *all* web content.

WG:
If forced to strictly use specifications you might be restricted from
doing things you want to do that would not be harmful to
accessibility.

GL:
Without using specifications correctly, there's a far higher risk of
introducing errors that do affect accessibility. Sailesh has already
put forward an argument about how id values that were not unique have
caused an accessibility issue. The broken CMSs that we're trying to
work around can also cause real accessibility barriers, too. I've seen
cases where CMSs have produced attribute values where some of the text
is quoted, sometimes making only part of the information available.
Validity stops these types of errors, which do result in real
accessibility barriers. Arguably, the group most effected by invalid
documents are those with cognitive difficulties. Because of the
incredible parsing capabilities of most modern user agents, most
invalid documents are rendered okay. When an invalid document isn't
rendered properly, the result can be difficult to decipher.

WG:
Current WYSIWYG and CMS tools do not necessarily generate valid code,
making it difficult or impossible for many authors to meet this SC.
(We cannot force authors to do manual coding to conform to WCAG.)

GL:
This isn't a reason *not to require* validity; it's a good reason *to
require* validity. Pandering to broken tools just perpetuates the
problems, and doesn't begin to resolve anything. The recommendations
made by WCAG should be promoting best practice to take the pressure
from user agents trying to decipher what's been given to them. If
validity wasn't an issue, we would have better user agents as they
wouldn't have to be so concerned with error correction. There are also
plenty of tools that do allow valid markup. Requiring validity at
priority 1 would encourage people to use tools that do generate valid
markup, rather than propagating the problem.

WG:
There are very strong commercial pressures for tools to include
features that are not strictly part of public specifications.

GL:
There are stronger social pressures not to pander to the commercial
pressures, and the social pressures should be the primary focus of
WCAG - people with disabilities. If tools absolutely must provide
features that are not part of public specifications, then they should
be using modular XHTML. Tools should be covered by ATAG, and WCAG
should be providing techniques for better accessibility, rather than
bending to commercial pressures. I appreciate you have to consider
commercial issues for acceptance, but I can't help thinking that
discrediting another W3C recommendation is like selling your soul.

WG:
We differentiate between well formedness and validity. Well formedness
can benefit accessibility. Validity can benefit accessibility though
there may be issues. Therefore, for now we have moved validity to
level 2. We will also investigate well formedness and expand it at
level 1.

GL:
An SGML language like HTML cannot be well-formed. 

Keeping validity at level 2, or removing it completely, gives a
message that validity is not important for accessibility. Most people
agree that whilst validity is no guarantee of accessible content, it
definitely provides a solid foundation on which to build
accessibility. Some arguments have been presented that valid documents
may not be accessible, such as a data table that isn't marked up
correctly. Being invalid wouldn't make it more accessible. That's the
reason why the other 12 guidelines exist.

I'm hoping to appeal to the software engineers amongst the working
group: testability is a fundamental software engineering principle. If
something is invalid, it cannot be tested, as the outcomes couldn't
possibly be known. Most invalid documents are very invalid. Each error
is compounded, and the permutations of what some people consider to be
little errors become impossible to guarantee any outcome. No
user-agent fully complies with UAAG. If user-agents didn't have to be
so concerned with validity, there's a stronger chance that more would
comply with other WAI recommendations.

I appreciate that there's an enormous amount of invalid legacy content
out there, and that nothing is going to change over night. My concern
is that by trivialising validity, we're propagating the issue. Most of
that invalid content will also contain accessibility barriers. A good
starting point will be to get the content valid, and then tackle the
accessibility.

I could go on and on, but I would like someone to read it :-)

Best regards,

Gez

[1] http://www.faqs.org/rfcs/rfc2119.html

-- 
_____________________________
Supplement your vitamins
http://juicystudio.com

Received on Wednesday, 22 June 2005 23:40:52 UTC