RE: Open AJAX redefining WCAG 2 requirements...

Thanks Sailesh

The working group I believe will be creating a note in the near future which
will articulate some of the misconceptions about WCAG 2.0, particularly with
respect to misunderstood WCAG 2.0 Success criteria that have an echo of the
previous WCAG 1.0 Checkpoints, but are distinct in the way they address the
accessibility issue.

Some of the problems of interpretation of WCAG 2.0 are based on
misinformation, and some are based on strong opinions that WCAG 2 should
have maintained this or that checkpoint of WCAG 1.

I think its fine for someone to say that web masters should do this or that
coding practice because of a strong conviction that it should be done that
way, but I think it is wrong to say WCAG 2.0 requires things that it
doesn't. WCAG 2.0 is a consensus document and there were no formal
objections that I know of. 

Personally, I'm not crazy about companies and government using up their
limited accessibility budgets chasing down issues that are better handled in
their "standards" budgets.

David MacDonald

 

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Sailesh Panchang
Sent: June-24-11 11:18 AM
To: 'WCAG'; David MacDonald
Subject: Re: Open AJAX redefining WCAG 2 requirements...

David,
These  (FONT, U and possibly they have missed CENTER) are deprecated tags.
WCAG 1 disallows deprecated tags. CSS use is advised instead.    
The problem is these rules have been on the books for nearly a decade prior
to WCAG 2 perhaps after some serious deliberation by the then WCAG-WG. So
use of deprecated tags is considered not good for accessibility.
(I do not understand why, except that their presentation effect will not go
away if CSS is turned off.  Browsers still support them and AT-users like me
are not impacted. Yet this was the rule of the land since 1999).  

The broader point is that it is not clear to many which of the guiding rules
of WCAG 1 now stand deprecated by WCAG 2 . Or why.  
Here is another example:
Vision impaired  AT users are seriously impacted if headings are not used in
sequence or heading levels are skipped. This was a clear requirement of WCAG
1 checkpoint 3.5 and I was so glad to see SC 1.3.1 of WCAG 2 and believed it
elevated the Priority-2 checkpoint to Level A. But the powers that be at
WCAG-WG have now decreed that it is alright if levels are skipped. They do
not consider it to be a serious accessibility issue but a mere 'best
practice'. I strongly disagree with this view. Why has using headings as per
specs become a mere best practice and not an accessibility requirement?   

So WCAG-WG clearly  needs to document all WCAG 1 checkpoints that are no
longer considered accessibility requirements with reasoning. It will have to
be better than merely saying the checkpoint is HTML specific. 
 Sailesh Panchang
www.deque.com


--- On Thu, 6/23/11, David MacDonald <david100@sympatico.ca> wrote:

From: David MacDonald <david100@sympatico.ca>
Subject: Open AJAX redefining WCAG 2 requirements...
To: "'WCAG'" <w3c-wai-gl@w3.org>
Date: Thursday, June 23, 2011, 7:27 PM

 It appears to me that the Open AJAX form have accepted an independent set
of violations of WCAG 2.0 that are distinct from the requirements of WCAG
2.0   http://www.oaa-accessibility.org/  For instance, the following appear
to be violations of 4.1.1....   IDStatusPrioritySeverityRule
Description17AcceptedPriority 2ViolationRule 17: Do not use the FONT element
to style text58AcceptedPriority 2ViolationRule 58: Do not use the B
element.59AcceptedPriority 2ViolationRule 59: Do not use the I
element.60AcceptedPriority 2ViolationRule 60: Do not use the U element.    

Received on Friday, 24 June 2011 17:49:52 UTC