E-mail List Archives
Thread: WCAG 2.0 'accessibility supported'
Number of posts in this thread: 17 (In chronological order)
From: Mark Magennis
Date: Fri, Feb 06 2009 3:45AM
Subject: WCAG 2.0 'accessibility supported'
No previous message | Next message →
Dear all,
I'm trying to get to grips with the concept of 'accessibility
supported' introduced in WCAG 2.0. Specifically, in relation to the
issue of ensuring that text can be resized by user agents.
Here's a hypothetical example. Suppose you have an HTML page
containing a single sentence of plain text: "The quick brown fox jumps
over the lazy dog". Suppose the size of the text is specified in
pixels, so the text cannot be resized in IE6 (with its default
settings).
1. Does the fact that many users use IE6 (with its default settings)
mean that the use of pixel values in HTML is not accessibility
supported? And if all users switch to using a browser that can resize
text specified in pixels, would that mean the use of pixel values is
now accessibility supported?
2. If the HTML page was removed and the same plain text sentence was
presented in a PDF file such that it could be resized by all user
agents that display PDFs, would that use of PDF be accessibility
supported?
3. Does this mean that whatever technology is used (HTML, PDF or
whatever), it is not the technology itself that is either
accessibility supported or not, but the way that technology is used or
the specific functionalities of the technology that are used?
Mark
********************************************************************
NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.
NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI
********************************************************************
From: Patrick Lauke
Date: Fri, Feb 06 2009 4:35AM
Subject: Re: WCAG 2.0 'accessibility supported'
← Previous message | Next message →
Here's my interpretation of it:
> Mark Magennis
> 1. Does the fact that many users use IE6 (with its default settings)
mean that the use of pixel values in HTML is not
> accessibility supported? And if all users switch to using a browser
that can resize text specified in pixels, would that
> mean the use of pixel values is now accessibility supported?
I'd say that yes, pixel values are ok because there are widely available
user agents that support resizing.
> 2. If the HTML page was removed and the same plain text sentence was
presented in a PDF file such that it could be resized
> by all user agents that display PDFs, would that use of PDF be
accessibility supported?
If the PDF was accessible in itself, yes.
> 3. Does this mean that whatever technology is used (HTML, PDF or
whatever), it is not the technology itself that is either
> accessibility supported or not, but the way that technology is used or
the specific functionalities of the technology
> that are used?
The former: it's a technology that is accessibility-supported (or, to be
more specific, the particular aspect of the technology that's used is
accessibility-supported - the technology as a whole may have parts that
are not supported, but you as an author only use the bit that is indeed
accessibility-supported).
P
From: Mark Magennis
Date: Fri, Feb 06 2009 5:20AM
Subject: Re: WCAG 2.0 'accessibility supported'
← Previous message | Next message →
> the technology as a whole may have parts that are not supported
Okay, so it would be wrong then to make a blanket statement that PDF
is not accessibility supported, since it's conceivable to create a
simple PDF that can be read by anyone using freely available user
agents. But it would be correct to say that a structured PDF is not
accessibility supported because only the latest screen readers can
read the essential structural markup and they are prohibitively costly
for a significant number of people.
Yes?
Mark
********************************************************************
NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.
NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI
********************************************************************
From: Steve Green
Date: Fri, Feb 06 2009 5:55AM
Subject: Re: WCAG 2.0 'accessibility supported'
← Previous message | Next message →
This is one of a number of areas where WCAG 2.0 has introduced ambiguity
where issues were clear in version 1.0. The issue of accessibility supported
technologies is now untestable, which is precisely the opposite of what the
W3C intended.
Th W3C acknowledge that there is a high degree of ambiguity in their
explanatory notes at
http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-
support-head and 'welcome discussion' even though it won't change anything.
Strictly speaking, Patrick is correct when he says "there are widely
available user agents that support resizing". However, 75% or so of Internet
users do not have such user agents. Furthermore, they have no way of knowing
that using a different user agent would allow the text to be resized. This
is a very different scenario from being prompted to install a plug-in that
you currently do not have.
I disagree with Patrick on the final point. To quote from the WCAG 2.0
explanatory notes,
"The way that the Web content technology is used must be supported by users'
assistive technology...
AND
The Web content technology must have accessibility-supported user agents
that are available to users"
In my opinion WCAG 2.0 is misconceived, badly written and will result in a
reduction in website accessibility. We all know that using pixel values for
fonts reduces accessibility. We all know that using PDFs reduces
accessibility. The fact that WCAG 2.0 says these techniques are ok doesn't
mean you're making an accessible website. It just means you are compliant
with a bad set of guidelines.
If you care about accessibility, do the right things (you know what they
are). If you just want the badge, take a literal interpretation of WCAG 2.0.
Steve
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Patrick Lauke
Sent: 06 February 2009 11:35
To: WebAIM Discussion List
Subject: Re: [WebAIM] WCAG 2.0 'accessibility supported'
Here's my interpretation of it:
> Mark Magennis
> 1. Does the fact that many users use IE6 (with its default settings)
mean that the use of pixel values in HTML is not
> accessibility supported? And if all users switch to using a browser
that can resize text specified in pixels, would that
> mean the use of pixel values is now accessibility supported?
I'd say that yes, pixel values are ok because there are widely available
user agents that support resizing.
> 2. If the HTML page was removed and the same plain text sentence was
presented in a PDF file such that it could be resized
> by all user agents that display PDFs, would that use of PDF be
accessibility supported?
If the PDF was accessible in itself, yes.
> 3. Does this mean that whatever technology is used (HTML, PDF or
whatever), it is not the technology itself that is either
> accessibility supported or not, but the way that technology is used or
the specific functionalities of the technology
> that are used?
The former: it's a technology that is accessibility-supported (or, to be
more specific, the particular aspect of the technology that's used is
accessibility-supported - the technology as a whole may have parts that are
not supported, but you as an author only use the bit that is indeed
accessibility-supported).
P
From: Benjamin Hawkes-Lewis
Date: Fri, Feb 06 2009 6:50AM
Subject: Re: WCAG 2.0 'accessibility supported'
← Previous message | Next message →
On 6/2/09 12:56, Steve Green wrote:
> Strictly speaking, Patrick is correct when he says "there are widely
> available user agents that support resizing". However, 75% or so of Internet
> users do not have such user agents.
I'm not sure it's strictly true that Internet Explorer 6 does not
support resize text sizes specified in pixels, although it's a
half-truth relevant to real-world usability.
Granted IE6 does not resize such text styles with the Text Size menu or
Windows High Contrast mode, but you can scale them by applying a user
stylesheet with IE's accessibility options and specifying the "zoom"
property in your stylesheet.
http://www.microsoft.com/enable/training/ie6/formatpage.aspx
http://msdn.microsoft.com/en-us/library/ms531189.aspx
Try this to test:
javascript:(function(){document.body.style.zoom="4";}())
Browser marketshare statistics are difficult to gather and interpret,
but the publically available statistics:
http://www.upsdell.com/BrowserNews/stat.htm
suggest that at least two thirds of users are using user agents other
than IE6. While neither IE7 nor IE8 resizes text sizes specified in
pixels with the Text Size menu, both include Zoom functionality in the
primary interface, removing even the need to use the user stylesheet
functionality.
> they have no way of knowing that using a different user agent would
> allow the text to be resized.
They may not know, but they have lots of ways to find out.
> This is a very different scenario from being prompted to install a plug-in that
> you currently do not have.
That's true, although it's a lot easier for a user to ask for help with
resizing text than to ask for help with plugins. There's less jargon
involved.
--
Benjamin Hawkes-Lewis
From: Steve Green
Date: Fri, Feb 06 2009 8:05AM
Subject: Re: WCAG 2.0 'accessibility supported'
← Previous message | Next message →
Real users just take what they see at face value. If they can't resize the
text with their browser then they assume it can't be resized. If their
browser lacks a feature, they don't go looking for another browser that
might have it because most people assume there is no difference between
them. And life's too short for what may turn out to be a fruitless search.
Zoom serves a different purpose and is not a suitable alternative for text
resizing in my opinion.
"it's a lot easier for a user to ask for help"
Ask who? In most domestic and office environments there's no one competent
to ask. And even when there is, people rarely do.
Steve
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Benjamin
Hawkes-Lewis
Sent: 06 February 2009 13:45
To: WebAIM Discussion List
Subject: Re: [WebAIM] WCAG 2.0 'accessibility supported'
On 6/2/09 12:56, Steve Green wrote:
> Strictly speaking, Patrick is correct when he says "there are widely
> available user agents that support resizing". However, 75% or so of
> Internet users do not have such user agents.
I'm not sure it's strictly true that Internet Explorer 6 does not support
resize text sizes specified in pixels, although it's a half-truth relevant
to real-world usability.
Granted IE6 does not resize such text styles with the Text Size menu or
Windows High Contrast mode, but you can scale them by applying a user
stylesheet with IE's accessibility options and specifying the "zoom"
property in your stylesheet.
http://www.microsoft.com/enable/training/ie6/formatpage.aspx
http://msdn.microsoft.com/en-us/library/ms531189.aspx
Try this to test:
javascript:(function(){document.body.style.zoom="4";}())
Browser marketshare statistics are difficult to gather and interpret, but
the publically available statistics:
http://www.upsdell.com/BrowserNews/stat.htm
suggest that at least two thirds of users are using user agents other than
IE6. While neither IE7 nor IE8 resizes text sizes specified in pixels with
the Text Size menu, both include Zoom functionality in the primary
interface, removing even the need to use the user stylesheet functionality.
> they have no way of knowing that using a different user agent would
> allow the text to be resized.
They may not know, but they have lots of ways to find out.
> This is a very different scenario from being prompted to install a
> plug-in that you currently do not have.
That's true, although it's a lot easier for a user to ask for help with
resizing text than to ask for help with plugins. There's less jargon
involved.
--
Benjamin Hawkes-Lewis
From: Randall Pope
Date: Fri, Feb 06 2009 8:15AM
Subject: Re: WCAG 2.0 'accessibility supported'
← Previous message | Next message →
Not to mention the assistive technology is not keeping with the latest web
design and its application. The reason behind this is of course little
money for research and development of new products.
With Warm Regards,
Randall "Randy" Pope
American Association of the Deaf-Blind
Website: http://www.aadb.org
301 495-4402 VP/TTY
301 495-4403 Voice
301 495-4404 Fax
AIM: RandyAADB
Want to keep up with the latest news in the Deaf-Blind Community? Consider
subscribing to the monthly newsletter, "AADB Today" at http://aadb.org. It's
free and AADB membership is not required.
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Steve Green
Sent: Friday, February 06, 2009 7:56 AM
To: 'WebAIM Discussion List'
Subject: Re: [WebAIM] WCAG 2.0 'accessibility supported'
This is one of a number of areas where WCAG 2.0 has introduced ambiguity
where issues were clear in version 1.0. The issue of accessibility supported
technologies is now untestable, which is precisely the opposite of what the
W3C intended.
Th W3C acknowledge that there is a high degree of ambiguity in their
explanatory notes at
http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-
support-head and 'welcome discussion' even though it won't change anything.
Strictly speaking, Patrick is correct when he says "there are widely
available user agents that support resizing". However, 75% or so of Internet
users do not have such user agents. Furthermore, they have no way of knowing
that using a different user agent would allow the text to be resized. This
is a very different scenario from being prompted to install a plug-in that
you currently do not have.
I disagree with Patrick on the final point. To quote from the WCAG 2.0
explanatory notes,
"The way that the Web content technology is used must be supported by users'
assistive technology...
AND
The Web content technology must have accessibility-supported user agents
that are available to users"
In my opinion WCAG 2.0 is misconceived, badly written and will result in a
reduction in website accessibility. We all know that using pixel values for
fonts reduces accessibility. We all know that using PDFs reduces
accessibility. The fact that WCAG 2.0 says these techniques are ok doesn't
mean you're making an accessible website. It just means you are compliant
with a bad set of guidelines.
If you care about accessibility, do the right things (you know what they
are). If you just want the badge, take a literal interpretation of WCAG 2.0.
Steve
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Patrick Lauke
Sent: 06 February 2009 11:35
To: WebAIM Discussion List
Subject: Re: [WebAIM] WCAG 2.0 'accessibility supported'
Here's my interpretation of it:
> Mark Magennis
> 1. Does the fact that many users use IE6 (with its default settings)
mean that the use of pixel values in HTML is not
> accessibility supported? And if all users switch to using a browser
that can resize text specified in pixels, would that
> mean the use of pixel values is now accessibility supported?
I'd say that yes, pixel values are ok because there are widely available
user agents that support resizing.
> 2. If the HTML page was removed and the same plain text sentence was
presented in a PDF file such that it could be resized
> by all user agents that display PDFs, would that use of PDF be
accessibility supported?
If the PDF was accessible in itself, yes.
> 3. Does this mean that whatever technology is used (HTML, PDF or
whatever), it is not the technology itself that is either
> accessibility supported or not, but the way that technology is used or
the specific functionalities of the technology
> that are used?
The former: it's a technology that is accessibility-supported (or, to be
more specific, the particular aspect of the technology that's used is
accessibility-supported - the technology as a whole may have parts that are
not supported, but you as an author only use the bit that is indeed
accessibility-supported).
P
From: Patrick Lauke
Date: Fri, Feb 06 2009 8:35AM
Subject: Re: WCAG 2.0 'accessibility supported'
← Previous message | Next message →
Ok Steve, so what do we do? Lowest common denominator design? Stick with
WCAG 1 and forget about the whole "accessibility supported" angle?
P
From: Rimantas Liubertas
Date: Fri, Feb 06 2009 10:55AM
Subject: Re: WCAG 2.0 'accessibility supported'
← Previous message | Next message →
> However, 75% or so of Internet
> users do not have such user agents. Furthermore, they have no way of knowing
> that using a different user agent would allow the text to be resized.
How many of these 75% percent do need text resizing, and how many do know
that this feature exists?
Where did you get this number anyway? Only IE<7 cannot increase text size,
does it have 75% of market share? If one believes net stats all versions of IE
have market share ~67% and IE6 has less than 30%.
Frankly, it is sad to see how this "px is non resizable in IE"
nonsense became the bike-shed of the web
accessibility and way too many just stuck on this overblown "problem"
and won't move on.
As for the WCAG — I'll stuck with WCAG Samurai for a while, thank you very much.
Regards,
Rimantas
--
http://rimantas.com/
http://rimantas.com/
From: Steve Green
Date: Fri, Feb 06 2009 11:05AM
Subject: Re: WCAG 2.0 'accessibility supported'
← Previous message | Next message →
We are still assessing our position on this, and at some point we will
produce a position paper. My current opinion is that "accessibility
supported" is a misconceived idea, and it undermines all the good work that
has been done with regard to "progressive enhancement".
The way WCAG 2 is written, "accessibility supported" is cop-out. It makes
the unreasonable expectation that users will be able to realise there is a
problem to solve, research it then procure and implement the solution. There
is not a hope in hell that the vast majority of people will be able to do
this.
If it were not for the commercial pressure to work to WCAG 2 we would
definitely stick to version 1 because it results in websites that are more
accessible. Sadly WCAG 2 has been written for the benefit of developers, not
for the end users.
Steve
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Patrick Lauke
Sent: 06 February 2009 15:33
To: WebAIM Discussion List
Subject: Re: [WebAIM] WCAG 2.0 'accessibility supported'
Ok Steve, so what do we do? Lowest common denominator design? Stick with
WCAG 1 and forget about the whole "accessibility supported" angle?
P
From: Waltenberger, Lon (LNI)
Date: Fri, Feb 06 2009 1:55PM
Subject: Re: WCAG 2.0 'accessibility supported'
← Previous message | Next message →
Bravo, Mr. Green, to all of your remarks about WCAG 2.0!
From: Steve Green
Date: Fri, Feb 06 2009 2:45PM
Subject: Re: WCAG 2.0 'accessibility supported'
← Previous message | Next message →
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Rimantas
Liubertas
Sent: 06 February 2009 17:54
To: WebAIM Discussion List
Subject: Re: [WebAIM] WCAG 2.0 'accessibility supported'
> However, 75% or so of Internet
> users do not have such user agents. Furthermore, they have no way of
> knowing that using a different user agent would allow the text to be
resized.
How many of these 75% percent do need text resizing, and how many do know
that this feature exists?
Where did you get this number anyway? Only IE<7 cannot increase text size,
does it have 75% of market share? If one believes net stats all versions of
IE have market share ~67% and IE6 has less than 30%.
Frankly, it is sad to see how this "px is non resizable in IE"
nonsense became the bike-shed of the web accessibility and way too many
just stuck on this overblown "problem"
and won't move on.
As for the WCAG - I'll stuck with WCAG Samurai for a while, thank you very
much.
Regards,
Rimantas
--
http://rimantas.com/
"How many of these 75% percent do need text resizing?"
My guess would be a percent or two. Doesn't sound much but developers seem
happy to put in the effort to support browsers such as Opera that have
similarly small usage.
"How many do know that this feature exists"
In my experience none. I have never met a single person outside the
development community who knew that text resizing is possible, far less how
to do it. I'm sure there are some, but they are extremely rare.
"Only IE<7 cannot increase text size"
As I stated before, the zoom feature is not a substitute for the ability to
resize text.
"stuck on this overblown "problem" and won't move on"
I base my opinions on the results of user testing, and will be the first to
move on just as soon as users stop having problems with resizing text.
"I'll stick with WCAG Samurai for a while"
I'm totally in agreement. The W3C should simply have adopted it instead of
persisting with WCAG 2.
Steve
From: Rahul Gonsalves
Date: Fri, Feb 06 2009 8:35PM
Subject: Re: WCAG 2.0 'accessibility supported'
← Previous message | Next message →
Mr. Green,
On 07-Feb-09, at 3:14 AM, Steve Green wrote:
> "Only IE<7 cannot increase text size"
>
> As I stated before, the zoom feature is not a substitute for the
> ability to resize text.
I would be interested in knowing why you say that the zoom feature is
not a substitute for resizing text? I am going to be conducting an
accessibility training session next week and would like to ensure that
I give out as much "correct" information as possible.
Thanks,
- Rahul.
From: Benjamin Hawkes-Lewis
Date: Sat, Feb 07 2009 2:25AM
Subject: Re: WCAG 2.0 'accessibility supported'
← Previous message | Next message →
On 6/2/09 15:06, Steve Green wrote:
> Real users just take what they see at face value. If they can't resize the
> text with their browser then they assume it can't be resized. If their
> browser lacks a feature, they don't go looking for another browser that
> might have it because most people assume there is no difference between
> them. And life's too short for what may turn out to be a fruitless search.
Okay, I suspect this is a "two camps" area of disagreement:
http://www.thepickards.co.uk/index.php/200609/the-usefulness-of-accessibility-audits/
http://accessites.org/site/2006/10/the-great-accessibility-camp-out/
http://www.isolani.co.uk/blog/access/BarCampLondon2AccessibilityPanelThoughts
http://joeclark.org/appearances/atmedia2007/
I think it's a mistake to conflate disinterest with disability, and
backwards compatibility with web accessibility. Catering to users who
just aren't that bothered and supporting older or alternative user
agents can be worthy goals, but it's useful to distinguish those aims
from ensuring sites are accessible to people with disabilities. Some
reasons for that:
* Making sites accessible to people with disabilities carries a greater
moral weight than the other two goals.
* Companies often have legal obligations to make sites accessible to
people with disabilities. It confuses the issue if we justify backwards
compatibility adjustments as though they were addressing those legal
obligations. (IANAL and I do admit the possibility that a court or
legislature could decide backwards compatibility is an essential
component of making sites accessible to people with disabilities, though
it seems unlikely to me.)
* "Google is blind" may be a good slogan when selling accessibility to
businesses, but it gets problematic if developers buy it wholesale. It's
important to be able to be able to prioritize these goals as they
sometimes conflict. For example, optimizing for people trying to find
content via search engine user agents can conflict with helping people
trying to consume content with screen readers in areas like text
equivalents, hidden text, heading choice, and source order.
* Packaging all three goals together can become a disincentive to
meeting any of the goals ("My Web 2.0 application doesn't work in IE6 or
Lynx or JAWS 4, so it can't be accessible, so I won't bother with alt
tags" or "My photo sharing site doesn't cater to blind people, so why
bother with web standards", etc.).
* Laying all three requirements at the feet of website developers
absolves users and user agent developers of their own responsibilities
in a way that is ultimately self-defeating. User and user agent
developers need to come to the table too:
http://www.w3.org/WAI/intro/components.php
Just last month, we had a thread on here with folks arguing that every
page should have a text resize widget because people don't know how to
use the Text Resize or Zoom commands on their browser:
http://www.webaim.org/discussion/mail_message.php?id=12287
http://www.webaim.org/discussion/mail_message.php?id=12291
http://www.webaim.org/discussion/mail_message.php?id=12294
Indeed, as you say in another message in this thread of the Text Resize
feature: "I have never met a single person outside the development
community who knew that text resizing is possible, far less how to do
it. I'm sure there are some, but they are extremely rare."
It seems to me if you take your logic of catering to users who aren't
willing to investigate how to improve their web experience seriously,
using px is irrelevant as you need to provide a text resize widget anyway.
I think the end result is a poor user experience, where every page is
crowded with omnipresent functionality that should be in user agents -
text resize widgets, skin selectors, text-to-speech, clocks, translation
and definition tools, print buttons - all implemented differently on the
sites that are willing to do so.
> Zoom serves a different purpose and is not a suitable alternative for text
> resizing in my opinion.
Why? Are you concerned about horizontal scroll? Do the fit-to-width
reflow capabilities of Opera and IE8 allay those concerns at all?
--
Benjamin Hawkes-Lewis
From: Randall Pope
Date: Sun, Feb 08 2009 2:20PM
Subject: Re: WCAG 2.0 'accessibility supported'
← Previous message | Next message →
"As I stated before, the zoom feature is not a substitute for the ability to
resize text."
Zoomtext and other screen magnification software use this very same
approach, used by IE7 and Firefox. How can one say this is unacceptable?
With Warm Regards,
Randall "Randy" Pope
American Association of the Deaf-Blind
Website: http://www.aadb.org
301 495-4402 VP/TTY
301 495-4403 Voice
301 495-4404 Fax
AIM: RandyAADB
Want to keep up with the latest news in the Deaf-Blind Community? Consider
subscribing to the monthly newsletter, "AADB Today" at http://aadb.org. It's
free and AADB membership is not required.
"As I stated before, the zoom feature is not a substitute for the ability to
resize text."
Zoomtext and other screen magnification software use this technique.
From: Webb, KerryA
Date: Sun, Feb 08 2009 3:25PM
Subject: Re: WCAG 2.0 'accessibility supported'
← Previous message | Next message →
Steve wrote:
>
> In my opinion WCAG 2.0 is misconceived, badly written and will result
in a
> reduction in website accessibility. We all know that using pixel
values
> for fonts reduces accessibility. We all know that using PDFs reduces
> accessibility. The fact that WCAG 2.0 says these techniques are ok
doesn't
> mean you're making an accessible website. It just means you are
compliant
> with a bad set of guidelines.
>
> If you care about accessibility, do the right things (you know what
they
> are). If you just want the badge, take a literal interpretation of
WCAG
> 2.0.
>
I'm glad you said that. My role is to write document on "website
standards" for agencies in our Government and to assist Web managers to
comply with these. We will be mandating compliance (at an appropriate
level) with WCAG 2.0 in the next few months, and I'll have to help our
people to achieve this. Even though they've had to comply with 1.0 for
several years, it won't be a trivial task to be 2.0 compliant, but we'll
do it.
I'm more concerned about the web managers who don't have a kind and
benevolent central authority to tell them what to do. Basically, I
think the WCAG 2.0 document is (as Steve says) misconceived and badly
written, and most people without a keen interest in accessibility will
find it hard to understand and to implement.
Kerry
-----------------------------------------------------------------------
This email, and any attachments, may be confidential and also privileged. If you are not the intended recipient, please notify the sender and delete all copies of this transmission along with any attachments immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person.
-----------------------------------------------------------------------
From: Patrick H. Lauke
Date: Sun, Feb 08 2009 3:35PM
Subject: Re: WCAG 2.0 'accessibility supported'
← Previous message | No next message
Webb, KerryA wrote:
> Basically, I
> think the WCAG 2.0 document is (as Steve says) misconceived and badly
> written, and most people without a keen interest in accessibility will
> find it hard to understand and to implement.
WCAG 2 is hard because it doesn't give black and white, yes / no
guidance and requires actual knowledge of accessibility on the part of
the implementer...but then again, real-life accessibility is not black
and white either.
IMHO, of course.
P
--
Patrick H. Lauke