E-mail List Archives
Thread: Procedure of making web accessibility testing.
Number of posts in this thread: 12 (In chronological order)
From: Rakesh Chowdary Paladugula
Date: Mon, Jun 08 2009 10:20PM
Subject: Procedure of making web accessibility testing.
No previous message | Next message →
Dear all,
I have a doubt from the beginning. I have a existing website with
1000 pages to be tested for web accessibility should I test all the
1000 pages or some selected pages . If so what are the pages I gave to
test.
One more issue is I will have websites under construction which will
be in local surver. Wave will not take the URL of the staging site. Is
the procedure used is file upload and copying the source code and
validate or is there any other procedure.
Thanks & regards
Rakesh Chowdary
Iridiuminteractive Limited
Changing a face doesn't change anything but facing a change changes everything.
From: Webb, KerryA
Date: Mon, Jun 08 2009 10:35PM
Subject: Re: Procedure of making web accessibility testing.
← Previous message | Next message →
Rakesh asked:
>
> Dear all,
> I have a doubt from the beginning. I have a existing website with
> 1000 pages to be tested for web accessibility should I test all the
> 1000 pages or some selected pages . If so what are the pages I gave to
> test.
It might be an idea to tell us why you want to test. If it's for some
form of certification, you'd probably have to test all pages. If, on
the other hand, it's to learn about what you'll need to do to make your
site generally more accessible then it may only be a case of testing
some representative page and applying what you learn from these and
extending it through the site.
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: Jared Smith
Date: Mon, Jun 08 2009 10:40PM
Subject: Re: Procedure of making web accessibility testing.
← Previous message | Next message →
Unless you are doing some final validation of accessibility that has
already been implemented, it makes little sense to test all of the
pages. I'd start with the popular pages and a representative sample of
other pages. This should give you a good idea of what you're doing
right or wrong.
To test intranet or other private pages in WAVE, you can upload, copy
and paste the code, or you can install the Firefox toolbar
(http://wave.webaim.org/toolbar). The toolbar is by far the easiest
because it checks the pages right within your browser window.
Jared Smith
WebAIM
From: Christophe Strobbe
Date: Tue, Jun 09 2009 2:55AM
Subject: Re: Procedure of making web accessibility testing.
← Previous message | Next message →
At 06:18 9/06/2009, Rakesh Chowdary Paladugula wrote:
>Dear all,
> I have a doubt from the beginning. I have a existing website with
>1000 pages to be tested for web accessibility should I test all the
>1000 pages or some selected pages . If so what are the pages I gave to
>test.
If you are looking for a sampling method, you could have a look at the
one in the "Unified Web Evaluation Methodology":
<http://www.wabcluster.org/uwem1_2/>;
See chapter 4, "Scope and sampling of resources" in the "Core" document.
Since you seem to know where all the pages of your website are, it
should be possible to create a fully random sample, as described in
section 4.3.2. (Section 4.3.1 describes a sampling method that can
be applied "manually".)
I'd be very interested to hear how this works for you.
Best regards,
Christophe Strobbe
>(...)
> Thanks & regards
>Rakesh Chowdary
>Iridiuminteractive Limited
--
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: Angela Colter
Date: Tue, Jun 09 2009 8:30AM
Subject: Re: Procedure of making web accessibility testing.
← Previous message | Next message →
Hi Rakesh,
I recently worked on an accessibility evaluation for a recently redesigned
association web site. Now, the full site has around 60,000 pages; there are
many, many content editors updating different areas of the site.
Because of the limited budget of the project, we reviewed a sample of 15
pages across the site, chosen by the client. While focusing on most popular
pages certainly makes sense, our samples were chosen in an effort to ensure
that the main content areas (each edited by a different group) were
represented. That way, no one could look at our results and think, "well,
that's a problem for THAT group, but not for ours." That was the thinking
behind choosing the sample, anyway.
What we found was there were two different types of accessibility errors:
errors in the design and errors in the content.
The "design" errors (such as text links that were styled so that the
underlines were removed) were located in the page templates, CSS, etc. These
errors would need to be corrected by folks with specialized knowledge or
access to fix these global issues. And because they were global, fixing them
once fixed them everywhere.
The "content" errors (such as poorly chosen or missing alt text) were
usually introduced by the content editors themselves. These are easy enough
to fix once the content editors understand what the errors are, how the
affect accessibility and how to fix them. The problem is, content errors are
very easy to reintroduce.
So by all means, do an accessibility review on a selection of pages. My
suggestion would be to consider your popular pages, critical tasks,
different page types (forms vs. pages, for example), and the different
content editors in your sample.
Where you find global issues in the design, fix them. Where you find errors
introduced by the content editors, focus your accessibility training efforts
to address the types of errors you're content editors are making.
Hope this helps,
Angela Colter
Usability / Accessibility Consultant
angelacolter.com
On Tue, Jun 9, 2009 at 12:18 AM, Rakesh Chowdary Paladugula <
= EMAIL ADDRESS REMOVED = > wrote:
> Dear all,
> I have a doubt from the beginning. I have a existing website with
> 1000 pages to be tested for web accessibility should I test all the
> 1000 pages or some selected pages . If so what are the pages I gave to
> test.
> One more issue is I will have websites under construction which will
> be in local surver. Wave will not take the URL of the staging site. Is
> the procedure used is file upload and copying the source code and
> validate or is there any other procedure.
> Thanks & regards
> Rakesh Chowdary
> Iridiuminteractive Limited
> Changing a face doesn't change anything but facing a change changes
> everything.
>
From: J. B-Vincent
Date: Tue, Jun 09 2009 10:50AM
Subject: Re: Procedure of making web accessibility testing.
← Previous message | Next message →
A tool I've been using lately for sampling pages is Link Sleuth, which is available free from http://home.snafu.de/tilman/xenulink.html. When it opens, hit Ctrl-N, and paste in the URL for the home page of the site you want to check. After it runs (and for some sites, it can take a looooong time), click on the "type" header, and then look for the "text/html" files. This helps me identify pages that may have distinct problems, as well as groups of pages likely to have common problems. It also gives me a clear overview of the site so I can make sure I'm getting a fair sample.
--Jane Vincent, Center for Accessible Technology
--- On Tue, 6/9/09, Angela Colter < = EMAIL ADDRESS REMOVED = > wrote:
From: Angela Colter < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Procedure of making web accessibility testing.
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Date: Tuesday, June 9, 2009, 7:27 AM
Hi Rakesh,
I recently worked on an accessibility evaluation for a recently redesigned
association web site. Now, the full site has around 60,000 pages; there are
many, many content editors updating different areas of the site.
Because of the limited budget of the project, we reviewed a sample of 15
pages across the site, chosen by the client. While focusing on most popular
pages certainly makes sense, our samples were chosen in an effort to ensure
that the main content areas (each edited by a different group) were
represented. That way, no one could look at our results and think, "well,
that's a problem for THAT group, but not for ours." That was the thinking
behind choosing the sample, anyway.
What we found was there were two different types of accessibility errors:
errors in the design and errors in the content.
The "design" errors (such as text links that were styled so that the
underlines were removed) were located in the page templates, CSS, etc. These
errors would need to be corrected by folks with specialized knowledge or
access to fix these global issues. And because they were global, fixing them
once fixed them everywhere.
The "content" errors (such as poorly chosen or missing alt text) were
usually introduced by the content editors themselves. These are easy enough
to fix once the content editors understand what the errors are, how the
affect accessibility and how to fix them. The problem is, content errors are
very easy to reintroduce.
So by all means, do an accessibility review on a selection of pages. My
suggestion would be to consider your popular pages, critical tasks,
different page types (forms vs. pages, for example), and the different
content editors in your sample.
Where you find global issues in the design, fix them. Where you find errors
introduced by the content editors, focus your accessibility training efforts
to address the types of errors you're content editors are making.
Hope this helps,
Angela Colter
Usability / Accessibility Consultant
angelacolter.com
On Tue, Jun 9, 2009 at 12:18 AM, Rakesh Chowdary Paladugula <
= EMAIL ADDRESS REMOVED = > wrote:
> Dear all,
> I have a doubt from the beginning. I have a existing website with
> 1000 pages to be tested for web accessibility should I test all the
> 1000 pages or some selected pages . If so what are the pages I gave to
> test.
> One more issue is I will have websites under construction which will
> be in local surver. Wave will not take the URL of the staging site. Is
> the procedure used is file upload and copying the source code and
> validate or is there any other procedure.
> Thanks & regards
> Rakesh Chowdary
> Iridiuminteractive Limited
> Changing a face doesn't change anything but facing a change changes
> everything.
>
From: Wayne Dick
Date: Tue, Jun 09 2009 12:10PM
Subject: Re: Procedure of making web accessibility testing.
← Previous message | Next message →
Another approach is to prioritize into
three groups: critical pages no more
than 100 pages; important pages 300,
less used and important pages:300; and
rarely used or unimportant sites 300.
Don't split hairs. Get help from
others to develop your picture.
Make sure the critical pages are fixed
right away. Walk through and test 20
to 40 of them and evaluate using
manual techniques. That should give a
good picture of the whole site - all
thousand pages. Next make a
prioritized maintenance schedule and
follow it. Each time a page comes up
for maintenance fix it. If you set
your schedule for 3 years then fix the
critical pages and 300 / year.
Finally, never add a new bad page to
your site.
Don't be frightened by manual
evaluation. I checked 400 pages by
hand in two weeks.
This method is called the
refurbishment model taken from
construction. It worked well in the
80's-90's for architectural barriers.
For the web it is better because web
pages don't last for centuries.
Legal concerns: Institutions that are
following a realistic plan will not
big problems with regulatory agencies.
The nice thing about this method is
that after 3 years many unimportant
pages have died already.
Wayne Dick
On Tue, 09 Jun 2009 10:50:33 +0200
Christophe Strobbe
< = EMAIL ADDRESS REMOVED = >
wrote:
>
> At 06:18 9/06/2009, Rakesh Chowdary
>Paladugula wrote:
>>Dear all,
>> I have a doubt from the beginning.
>>I have a existing website with
>>1000 pages to be tested for web
>>accessibility should I test all the
>>1000 pages or some selected pages .
>>If so what are the pages I gave to
>>test.
>
> If you are looking for a sampling
>method, you could have a look at the
> one in the "Unified Web Evaluation
>Methodology":
> <http://www.wabcluster.org/uwem1_2/>;
> See chapter 4, "Scope and sampling
>of resources" in the "Core" document.
>
> Since you seem to know where all the
>pages of your website are, it
> should be possible to create a fully
>random sample, as described in
> section 4.3.2. (Section 4.3.1
>describes a sampling method that can
> be applied "manually".)
> I'd be very interested to hear how
>this works for you.
>
> Best regards,
>
> Christophe Strobbe
>
>>(...)
>> Thanks & regards
>>Rakesh Chowdary
>>Iridiuminteractive Limited
>
>
> --
> 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: Karl Groves
Date: Tue, Jun 09 2009 12:55PM
Subject: Re: Procedure of making web accessibility testing.
← Previous message | Next message →
From an auditing standpoint - and in consideration of the production techniques of modern websites and web based applications - the best approach for thorough, qualitative data is to test representative sets of content based on media type. This is for a few reasons:
First, website interfaces are now often constructed with some sort of template system. The example I like to use most is the CNN website. Going to that site, you'll observe that every page within the 'www.cnn.com' domain has the same header. Imagine for a moment that the 'Powered by Google' image next to the "Search" button had no alt text. Because this is the same exact code calling this image, you only need to report on that missing alt text once. Find it once, fix it once, and the issue is remediated across the whole system. It would be an inefficient use of auditor (and developer, and stakeholder) time to continuously find & report on the same issues. From an auditing standpoint, their efforts would be best reserved for finding new problems, not ones they already know about.
Somewhat related is the idea that developers typically have their own "patterns" to the way they develop things. Generally speaking, a developer who doesn't make one data table correctly won't make any of them correctly. Of course there might be instances where an otherwise good developer will miss something, for the most part if you test a handful of similar items you'll get the qualitative data you need in order to make the necessary remediation recommendations. So, carve out portions of the interface into media types (i.e. "tables", "forms", "images", etc.) and test a few representative samples of each rather than testing every single one.
Karl
----- Original Message -----
From: "Angela Colter" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, June 9, 2009 10:27:47 AM GMT -05:00 US/Canada Eastern
Subject: Re: [WebAIM] Procedure of making web accessibility testing.
Hi Rakesh,
I recently worked on an accessibility evaluation for a recently redesigned
association web site. Now, the full site has around 60,000 pages; there are
many, many content editors updating different areas of the site.
Because of the limited budget of the project, we reviewed a sample of 15
pages across the site, chosen by the client. While focusing on most popular
pages certainly makes sense, our samples were chosen in an effort to ensure
that the main content areas (each edited by a different group) were
represented. That way, no one could look at our results and think, "well,
that's a problem for THAT group, but not for ours." That was the thinking
behind choosing the sample, anyway.
What we found was there were two different types of accessibility errors:
errors in the design and errors in the content.
The "design" errors (such as text links that were styled so that the
underlines were removed) were located in the page templates, CSS, etc. These
errors would need to be corrected by folks with specialized knowledge or
access to fix these global issues. And because they were global, fixing them
once fixed them everywhere.
The "content" errors (such as poorly chosen or missing alt text) were
usually introduced by the content editors themselves. These are easy enough
to fix once the content editors understand what the errors are, how the
affect accessibility and how to fix them. The problem is, content errors are
very easy to reintroduce.
So by all means, do an accessibility review on a selection of pages. My
suggestion would be to consider your popular pages, critical tasks,
different page types (forms vs. pages, for example), and the different
content editors in your sample.
Where you find global issues in the design, fix them. Where you find errors
introduced by the content editors, focus your accessibility training efforts
to address the types of errors you're content editors are making.
Hope this helps,
Angela Colter
Usability / Accessibility Consultant
angelacolter.com
On Tue, Jun 9, 2009 at 12:18 AM, Rakesh Chowdary Paladugula <
= EMAIL ADDRESS REMOVED = > wrote:
> Dear all,
> I have a doubt from the beginning. I have a existing website with
> 1000 pages to be tested for web accessibility should I test all the
> 1000 pages or some selected pages . If so what are the pages I gave to
> test.
> One more issue is I will have websites under construction which will
> be in local surver. Wave will not take the URL of the staging site. Is
> the procedure used is file upload and copying the source code and
> validate or is there any other procedure.
> Thanks & regards
> Rakesh Chowdary
> Iridiuminteractive Limited
> Changing a face doesn't change anything but facing a change changes
> everything.
>
From: Rakesh Chowdary Paladugula
Date: Tue, Jun 09 2009 11:20PM
Subject: Re: Web accessibility testing procedure.
← Previous message | Next message →
Hello Jared Smith,
Thankyou for your help in this regard.
I am a visually impaired person and a JAWS user , does wave
accessibility tool for firefox works with JAWS 10 , If so can you
point me where I can get the information about the same.
-------Jared Smith wrote…….
Unless you are doing some final validation of accessibility that has
already been implemented, it makes little sense to test all of the
pages. I'd start with the popular pages and a representative sample of
other pages. This should give you a good idea of what you're doing
right or wrong.
To test intranet or other private pages in WAVE, you can upload, copy
and paste the code, or you can install the Firefox toolbar
(http://wave.webaim.org/toolbar). The toolbar is by far the easiest
because it checks the pages right within your browser window.
Jared Smith
WebAIM
--
Thanks & regards
Rakesh
Iridium Interactive Limited
Changing a face doesn't change anything, facing a change changes everything.
From: Jared Smith
Date: Wed, Jun 10 2009 7:20AM
Subject: Re: Web accessibility testing procedure.
← Previous message | Next message →
Yes, the WAVE evaluation tool does work with screen readers. The tool,
by it's nature, is a visual tool, but it does include alternative text
and other accessibility features. In general, WAVE will insert icons
into the original page to indicate accessibility errors, alerts,
features, or semantic/structural elements. If you hear these key words
on images, you'll know that the icon applies to an element adjacent to
that icon.
WAVE does not fix accessibility issues in the page, so if you evaluate
a page with accessibility problems, those problems won't automatically
go away as you read it, but they will be identified by the WAVE icons.
In Firefox, you can run a WAVE report by selecting Alt + T... then
navigate to WAVE..., then select the right arrow key, and then select
the WAVE report you want to run. This opens the Tools... WAVE...
report functionality. You can also run a WAVE report by opening the
context menu (the key between right the right Alt and Control keys),
then arrowing up WAVE, and then arrowing over to the desired option.
You can also go to the WAVE... Options... menu and set your own custom
shortcut key for each WAVE report type.
If you have any feedback on how we can make WAVE more screen reader
friendly, please send them to me off-list.
Jared Smith
WebAIM
From: Jon Gunderson
Date: Wed, Jun 10 2009 8:10AM
Subject: Re: Procedure of making web accessibility testing.
← Previous message | Next message →
A free service from the university of Illinois can be used to test multiple pages as part of an accessibility audit program:
http://fae.cita.illinois.edu/
You must sign up for a free user account to test multiple pages:
http://fae.cita.illinois.edu/accounts/register/
Accessibility reports can be archived and the URL to the report can easily be shared to provide feedback to developers and administrators on accessibility problems.
The rules used in FAE are based on the iCITA best practices:
http://html.cita.uiuc.edu
Jon
---- Original message ----
>Date: Tue, 9 Jun 2009 09:47:19 -0700 (PDT)
>From: "J. B-Vincent" < = EMAIL ADDRESS REMOVED = >
>Subject: Re: [WebAIM] Procedure of making web accessibility testing.
>To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>
>A tool I've been using lately for sampling pages is Link Sleuth, which is available free from http://home.snafu.de/tilman/xenulink.html. When it opens, hit Ctrl-N, and paste in the URL for the home page of the site you want to check. After it runs (and for some sites, it can take a looooong time), click on the "type" header, and then look for the "text/html" files. This helps me identify pages that may have distinct problems, as well as groups of pages likely to have common problems. It also gives me a clear overview of the site so I can make sure I'm getting a fair sample.
>
>--Jane Vincent, Center for Accessible Technology
>
>--- On Tue, 6/9/09, Angela Colter < = EMAIL ADDRESS REMOVED = > wrote:
>
>From: Angela Colter < = EMAIL ADDRESS REMOVED = >
>Subject: Re: [WebAIM] Procedure of making web accessibility testing.
>To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>Date: Tuesday, June 9, 2009, 7:27 AM
>
>Hi Rakesh,
>
>I recently worked on an accessibility evaluation for a recently redesigned
>association web site. Now, the full site has around 60,000 pages; there are
>many, many content editors updating different areas of the site.
>
>Because of the limited budget of the project, we reviewed a sample of 15
>pages across the site, chosen by the client. While focusing on most popular
>pages certainly makes sense, our samples were chosen in an effort to ensure
>that the main content areas (each edited by a different group) were
>represented. That way, no one could look at our results and think, "well,
>that's a problem for THAT group, but not for ours." That was the thinking
>behind choosing the sample, anyway.
>
>What we found was there were two different types of accessibility errors:
>errors in the design and errors in the content.
>
>The "design" errors (such as text links that were styled so that the
>underlines were removed) were located in the page templates, CSS, etc. These
>errors would need to be corrected by folks with specialized knowledge or
>access to fix these global issues. And because they were global, fixing them
>once fixed them everywhere.
>
>The "content" errors (such as poorly chosen or missing alt text) were
>usually introduced by the content editors themselves. These are easy enough
>to fix once the content editors understand what the errors are, how the
>affect accessibility and how to fix them. The problem is, content errors are
>very easy to reintroduce.
>
>So by all means, do an accessibility review on a selection of pages. My
>suggestion would be to consider your popular pages, critical tasks,
>different page types (forms vs. pages, for example), and the different
>content editors in your sample.
>
>Where you find global issues in the design, fix them. Where you find errors
>introduced by the content editors, focus your accessibility training efforts
>to address the types of errors you're content editors are making.
>
>Hope this helps,
>
>Angela Colter
>
>Usability / Accessibility Consultant
>angelacolter.com
>
>On Tue, Jun 9, 2009 at 12:18 AM, Rakesh Chowdary Paladugula <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Dear all,
>> I have a doubt from the beginning. I have a existing website with
>> 1000 pages to be tested for web accessibility should I test all the
>> 1000 pages or some selected pages . If so what are the pages I gave to
>> test.
>> One more issue is I will have websites under construction which will
>> be in local surver. Wave will not take the URL of the staging site. Is
>> the procedure used is file upload and copying the source code and
>> validate or is there any other procedure.
>> Thanks & regards
>> Rakesh Chowdary
>> Iridiuminteractive Limited
>> Changing a face doesn't change anything but facing a change changes
>> everything.
>>
From: Clerkendweller
Date: Thu, Jun 11 2009 3:50AM
Subject: Re: Procedure of making web accessibility testing.
← Previous message | No next message
Christoph, thanks for the link to "Unified Web Evaluation Methodology".
> Kerry said:
> It might be an idea to tell us why you want to test. If it's
> for some form of certification, you'd probably have to test all pages.
Important point.
I suppose if you were making a WCAG2 conformance claim, every Web Page
(see definition) would have to be verified, not just a sample.
http://www.w3.org/TR/WCAG20/#conformance
But if you were an auditor subsequently checking this, then a sample
may be appropriate.
Colin Watson
http://www.watsonhall.com/