E-mail List Archives
Thread: WCAG 2 and Javascript
Number of posts in this thread: 8 (In chronological order)
From: Paul Collins
Date: Wed, May 13 2009 3:45AM
Subject: WCAG 2 and Javascript
No previous message | Next message →
Hi all,
I'm about to embark on a project that requires Flash. It needs to be accessible, so we were considering using Javascript instead, but then the same site would not work with scripts turned off. I'm still trying to catch up on WCAG 2 and I seem to be running around in circles trying to find the answer here, so thought I would ask the experts :)
- Do sites still have to work with all scripts turned off? Or can we use "Accessible" Javascript, like here:
http://www.w3.org/TR/WCAG20-TECHS/client-side-script.html
- Do all fonts need to be scaleable these days, or can we use image replacement, such as a graphic to replace the text?
Would appreciate your help. If anyone can show me a site that simplifies the WCAG 2, would greatly appreciate it!
Cheers
Paul
From: Steve Green
Date: Wed, May 13 2009 4:25AM
Subject: Re: WCAG 2 and Javascript
← Previous message | Next message →
- Do sites still have to work with all scripts turned off? Or can we use
"Accessible" Javascript, like here:
http://www.w3.org/TR/WCAG20-TECHS/client-side-script.html
- Do all fonts need to be scaleable these days, or can we use image
replacement, such as a graphic to replace the text?
Would appreciate your help. If anyone can show me a site that simplifies the
WCAG 2, would greatly appreciate it!
--
With regard to JavaScript you are asking two separate questions. JavaScript
is an 'accessibility supported technology', so according to WCAG 2.0 you can
use JavaScript as long as you do so in a manner that is accessible.
The consensus seems to be that a site does not have to work with JavaScript
turned off as long as one of a number of criteria are met e.g. that a user
agent is easily and cheaply available that does support JavaScript.
In my view this is entirely unsatisfactory but it's what WCAG 2.0 says.
Basically it's telling users to get a new user agent if the one they have
doesn't support JavaScript. Never mind that they may not know how to or may
not have the necessary permissions to do so.
With regard to scalable fonts, you cannot use image replacement. Although
you could scale the image proportionally to the text size (yuck), the text
and background colours cannot be changed according to the user's preference.
I would also regard sIFR as being non-compliant for the same reason,
although it is less bad than image replacement because the quality does not
degrade when it is scaled.
A simplified version of WCAG 2.0? No chance. In fact it's going to get more
complicated because the WAI are hoping that people will continuously add to
the already vast quantity of documentation. In particular they would like to
see technology-specific interpretations of the technology-independent
success criteria. Rather like WCAG 1.0. Remind me what was the point of WCAG
2.0?
Steve Green
Director
Test Partners Ltd
From: Paul Collins
Date: Wed, May 13 2009 4:30AM
Subject: Re: WCAG 2 and Javascript
← Previous message | Next message →
Thanks for your help Steve, much appreciated. I found the comparison chart here: http://wipa.org.au/papers/wcag-migration.htm and the WebAIM Checklist, which has helped make a bit more sense of it also.
http://www.webaim.org/standards/wcag/checklist/
You are absolutely right though; all that time drafting it and it seems to have made things more complicated!
Cheers
Paul
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Steve Green
Sent: Wednesday, May 13, 2009 11:20 AM
To: 'WebAIM Discussion List'
Subject: Re: [WebAIM] WCAG 2 and Javascript
- Do sites still have to work with all scripts turned off? Or can we use "Accessible" Javascript, like here:
http://www.w3.org/TR/WCAG20-TECHS/client-side-script.html
- Do all fonts need to be scaleable these days, or can we use image replacement, such as a graphic to replace the text?
Would appreciate your help. If anyone can show me a site that simplifies the WCAG 2, would greatly appreciate it!
--
With regard to JavaScript you are asking two separate questions. JavaScript is an 'accessibility supported technology', so according to WCAG 2.0 you can use JavaScript as long as you do so in a manner that is accessible.
The consensus seems to be that a site does not have to work with JavaScript turned off as long as one of a number of criteria are met e.g. that a user agent is easily and cheaply available that does support JavaScript.
In my view this is entirely unsatisfactory but it's what WCAG 2.0 says.
Basically it's telling users to get a new user agent if the one they have doesn't support JavaScript. Never mind that they may not know how to or may not have the necessary permissions to do so.
With regard to scalable fonts, you cannot use image replacement. Although you could scale the image proportionally to the text size (yuck), the text and background colours cannot be changed according to the user's preference.
I would also regard sIFR as being non-compliant for the same reason, although it is less bad than image replacement because the quality does not degrade when it is scaled.
A simplified version of WCAG 2.0? No chance. In fact it's going to get more complicated because the WAI are hoping that people will continuously add to the already vast quantity of documentation. In particular they would like to see technology-specific interpretations of the technology-independent success criteria. Rather like WCAG 1.0. Remind me what was the point of WCAG 2.0?
Steve Green
Director
Test Partners Ltd
From: Patrick H. Lauke
Date: Wed, May 13 2009 4:45AM
Subject: Re: WCAG 2 and Javascript
← Previous message | Next message →
On Wed, May 13, 2009 at 11:19 AM, Steve Green
< = EMAIL ADDRESS REMOVED = > wrote:
> A simplified version of WCAG 2.0? No chance. In fact it's going to get more
> complicated because the WAI are hoping that people will continuously add to
> the already vast quantity of documentation. In particular they would like to
> see technology-specific interpretations of the technology-independent
> success criteria. Rather like WCAG 1.0. Remind me what was the point of WCAG
> 2.0?
Steve, I trust that you passed on all of your concerns when WCAG 2.0
was in its last call?
And what would you prefer? Sticking with WCAG 1.0, in all its outdated
glory that does not aknowledge any of today's web (other than simply
saying "don't do it")? Or a static document that sets out exact SCs
for each individual technology, making it again instantly outdated as
soon as new tech gets used?
Back in 1999 there were only a handful of technologies available, and
sites were simple...nowadays, with the number of technologies,
complexity of online systems, etc, real accessibility is a complex
topic, which unfortunately can't be boiled down into a simple 5 page
tech requirements document.
</rant>
--
Patrick H. Lauke
From: Christophe Strobbe
Date: Wed, May 13 2009 4:50AM
Subject: Re: WCAG 2 and Javascript
← Previous message | Next message →
At 12:19 13/05/2009, Steve Green wrote:
>- Do sites still have to work with all scripts turned off? Or can we use
>"Accessible" Javascript, like here:
>http://www.w3.org/TR/WCAG20-TECHS/client-side-script.html
>
>- Do all fonts need to be scaleable these days, or can we use image
>replacement, such as a graphic to replace the text?
>
>Would appreciate your help. If anyone can show me a site that simplifies the
>WCAG 2, would greatly appreciate it!
>
>--
>
>
>With regard to JavaScript you are asking two separate questions. JavaScript
>is an 'accessibility supported technology', so according to WCAG 2.0 you can
>use JavaScript as long as you do so in a manner that is accessible.
It's not quite that simple.
1. Accessibility support for a technology is not a black-and-white
question, but one with many shades of grey.
Usually, certain features of a technology are not supported, but if
you don't rely on them, that is not a problem.
What counts is the features and techniques you use: it's these
features and techniques that need to be accessibility supported, even
if not ALL of the technology is accessibility supported.
2. There is another reason why you can simply say: "Technology X is
accessibility supported", namely that is sometimes depends on the
language of the content. If you develop content in English, you need
to look at support of user agents and AT that support English, but if
you develop content in Japanese, you'll need to look at support of
user agents and AT that support. So the set of accessibility
supported (uses of) technologies may vary depending on the language
of your content.
>The consensus seems to be that a site does not have to work with JavaScript
>turned off as long as one of a number of criteria are met e.g. that a user
>agent is easily and cheaply available that does support JavaScript.
>
>In my view this is entirely unsatisfactory but it's what WCAG 2.0 says.
>Basically it's telling users to get a new user agent if the one they have
>doesn't support JavaScript. Never mind that they may not know how to or may
>not have the necessary permissions to do so.
I disagree: it's telling developers to avoid (uses of) technologies
that are not accessibility supported.
>(...)
>A simplified version of WCAG 2.0? No chance. In fact it's going to get more
>complicated because the WAI are hoping that people will continuously add to
>the already vast quantity of documentation. In particular they would like to
>see technology-specific interpretations of the technology-independent
>success criteria. Rather like WCAG 1.0. Remind me what was the point of WCAG
>2.0?
The *criteria* are technology-agnostic, but that makes them harder to
use by developers. That why we need technology-specific *techniques*
and other documentation. Having this technology-specific techniques
does not make the criteria technology-dependent.
Best regards,
Christophe
>Steve Green
>Director
>Test Partners Ltd
--
Christophe Strobbe
K.U.Leuven - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
B-3001 Leuven-Heverlee
BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/
---
"Better products and services through end-user empowerment"
http://www.usem-net.eu/
---
Please don't invite me to LinkedIn, Facebook, Quechup or other
"social networks". You may have agreed to their "privacy policy", but
I haven't.
From: Steve Green
Date: Wed, May 13 2009 6:25AM
Subject: Re: WCAG 2 and Javascript
← Previous message | Next message →
Steve, I trust that you passed on all of your concerns when WCAG 2.0 was in
its last call?
And what would you prefer? Sticking with WCAG 1.0, in all its outdated glory
that does not aknowledge any of today's web (other than simply saying "don't
do it")? Or a static document that sets out exact SCs for each individual
technology, making it again instantly outdated as soon as new tech gets
used?
Back in 1999 there were only a handful of technologies available, and sites
were simple...nowadays, with the number of technologies, complexity of
online systems, etc, real accessibility is a complex topic, which
unfortunately can't be boiled down into a simple 5 page tech requirements
document.
--
Patrick, you are taking a developer-centric view, but the WCAG are not
supposed to be about developers - they are about the users. I take a
user-centric view, and my opinions are based on the results I see in user
testing. And what I see is that all these new technologies cause
accessibility barriers that did not used to exist.
As they stand, the guidelines are impenetrable to most people, and I fear
that even fewer developers will attempt to follow them. And we are now
seeing AA-compliant websites that have very poor 'real world' accessibility,
which has been a concern from the start.
I have no problem with people who want to use PDFs, Flash or whatever
technology they want. Just don't try to pretend they are accessible because
they are not (or at least they present significant barriers). WCAG 2.0 gives
a false sense of confidence, and that's why I don't like it.
Steve
From: Patrick H. Lauke
Date: Wed, May 13 2009 7:25AM
Subject: Re: WCAG 2 and Javascript
← Previous message | Next message →
On Wed, May 13, 2009 at 1:20 PM, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
> Patrick, you are taking a developer-centric view, but the WCAG are not
> supposed to be about developers - they are about the users. I take a
> user-centric view,
Well, because of the fact that you were talking about the reams of
documentation and how people are supposed to contribute to them, I
thought you were talking about the techniques, so dev centric. The
core normative WCAG 2.0 is done and dusted, and won't grow with any
new technologies etc...
> And what I see is that all these new technologies cause
> accessibility barriers that did not used to exist.
There are also lots of technologies now that did not use to
exist...but they do now, and rather than having a blanket "don't use
it, *ever*, because a subset of users may not have access to them
yet", it ensures that these technologies are at least used
responsibly, so that in modern user agents under all the right
conditions, they are accessible. The decision about whether or not to
actually use a technology (even if it's "accessibility-supported")
still rests with the business owners, developers, etc. Just as the
decision of using, say, CSS-based layout rather than table-based
layout etc rests with them.
> As they stand, the guidelines are impenetrable to most people, and I fear
> that even fewer developers will attempt to follow them.
I really don't get what's so impenetrable about the mostly
common-sense, tech agnostic WCAG 2.0 normative document. Sure, there's
a few bits here and there which could have been worded slightly
better, but overall I find it fairly clear. If you print out just the
Guidelines/SCs, it's just over 12 pages or so. And it takes a
user-centric view.
> And we are now
> seeing AA-compliant websites that have very poor 'real world' accessibility,
> which has been a concern from the start.
> I have no problem with people who want to use PDFs, Flash or whatever
> technology they want. Just don't try to pretend they are accessible because
> they are not (or at least they present significant barriers). WCAG 2.0 gives
> a false sense of confidence, and that's why I don't like it.
But if you make the conscious decision to use PDF, Flash etc, and you
follow the advice of WCAG 2.0, you're ensuring that those technologies
are at least used in a way that can be accessible. Whether the
percentage of users that potentially can't access it because of
outdated tech is, like any other consideration ("do we support
pixel-perfect layout in IE6, 5.5, Mosaic?"), something that needs to
be evaluated on a case-by-case basis. Certainly, even following WCAG
2.0 doesn't guarantee "universal accessibility", but the same can be
said for WCAG 1.0.
The classic situations mentioned where users can't get the most
up-to-date platforms to take advantage of accessibility-supported
technologies (can't afford a new screenreader, don't know how to
update the browser, don't have enough permissions to install any new
software) are beyond the scope of a document that deals with making
web content accessible, and fall under the responsibility of other
bodies/guidelines/etc (user education through disability advice
groups, an employer's legal obligation to ensure employees with access
needs have the right tools to do their job, etc).
P
--
Patrick H. Lauke
From: Steve Green
Date: Wed, May 13 2009 9:55AM
Subject: Re: WCAG 2 and Javascript
← Previous message | No next message
Hi Steve,
I've been looking for examples of this. Can you send me pointers. Thanks!
~Shawn
-----
In most cases these are sites our clients have asked us to audit, so I can't
really point the finger at them.
A common problem is where JavaScript is used to create multiple pages within
a page (to give the impression of tabs) or complex hide/reveal
functionality. Even when this is implemented in an 'accessible' manner, we
often find problems with user testing. Screen reader users often cannot form
and maintain a mental model of the page as it changes, and that is a
lmiitation of human beings, not the assistive technology. Often the Back
button does not work properly, which affects all users.
Flash content is a particular problem for users with voice recognition
software because even the most recent products see Flash as a black box.
However, the user typically knows nothing about web technologies, so they
just see text and images and wonder why they cannot interact with them.
It would be great if Nuance and Adobe would get together and sort out an API
that makes Flash content behave like text, images, buttons etc, but what's
the chance of that. Any solution that requires users to recognise Flash
content isn't a solution (e.g. using mousegrid).
Steve