E-mail List Archives
Thread: Bringing accessibility into the development process(request for feedback).
Number of posts in this thread: 16 (In chronological order)
From: Peter Krantz
Date: Mon, Apr 16 2007 6:10AM
Subject: Bringing accessibility into the development process(request for feedback).
No previous message | Next message →
Hi!
First: sorry if this comes through like a shameless plug. It is not the
intention. Secondly: sorry for the long post.
I have been thnking about ways to bring accessibility into the development
process [1]<http://www.standards-schmandards.com/2007/rapid-accessibility-feedback/>;and
make it a normal part of development activities. In my experience
accessibility evaluations are conducted at the end of a project. Testing at
the end makes it a lot harder to fix errors and they typically cost more to
fix.
To bring accessibility into a development project I have tried a couple of
things and discovered some challenges:
- Many developers know little about accessibility implications
emerging from their coding decisions.
- Accessibility evaluation is often conducted by experts outside the
development team.
- Aspects of accessibility (e.g. visual design, markup, content) is
not clearly mapped to areas of responsibility in a development team.
To get accessibility into the development process I have focused on
automated evaluation of markup accessibility issues. The idea is that if you
can make a basic markup accessibility check part of other automated tests
there will be alot less errors discovered at the end of the project. Many of
the existing tools today are not automatable and require a lot of expertise
to go understand the result.
For this purpose I am trying to make it possible to integrate Raakt (the
Ruby Accessibility Analysis Kit)
[2]<http://www.peterkrantz.com/raakt/wiki/>;into some of the popular
acceptance testing frameworks.
I would be grateful for your feedback on my ideas. Could this type of basic
testing be valuable? In your experience, are my observations valid?
[1]: http://www.standards-schmandards.com/2007/rapid-accessibility-feedback/
[2]: http://www.peterkrantz.com/raakt/wiki/
Thank you for your time.
Regards,
Peter Krantz
From: Jon Gunderson
Date: Mon, Apr 16 2007 8:20AM
Subject: Re: Bringing accessibility into the development process (request for feedback).
← Previous message | Next message →
A tool we are developing at the University of Illinois is trying to go beyond traditional accessibility checking and providing additional evaluation information on the presence of functional accessibility features.
Sign up for a free Functional Web Accessibility Evaluation (FAE) account to test entire websites or without an account you can test one page at a time:
http://fae.cita.uiuc.edu
NOTE: Accounts are needed to keep spam bots out
If your pages use scripting to generate some or all of the rendered content you can use the Firefox Accessibility Extension to send the dynamic generated html to FAE for evaluation.
http://firefox.cita.uiuc.edu
Use the Tools -> FAE Report option in the menu or the Toolbar to generate an FAE report on the dynamic content.
Jon
---- Original message ----
>Date: Mon, 16 Apr 2007 14:02:51 +0200
>From: "Peter Krantz" < = EMAIL ADDRESS REMOVED = >
>Subject: [WebAIM] Bringing accessibility into the development process (request for feedback).
>To: = EMAIL ADDRESS REMOVED =
>
>Hi!
>
>First: sorry if this comes through like a shameless plug. It is not the
>intention. Secondly: sorry for the long post.
>
>I have been thnking about ways to bring accessibility into the development
>process [1]<http://www.standards-schmandards.com/2007/rapid-accessibility-feedback/>;and
>make it a normal part of development activities. In my experience
>accessibility evaluations are conducted at the end of a project. Testing at
>the end makes it a lot harder to fix errors and they typically cost more to
>fix.
>
>To bring accessibility into a development project I have tried a couple of
>things and discovered some challenges:
>
> - Many developers know little about accessibility implications
> emerging from their coding decisions.
> - Accessibility evaluation is often conducted by experts outside the
> development team.
> - Aspects of accessibility (e.g. visual design, markup, content) is
> not clearly mapped to areas of responsibility in a development team.
>
>To get accessibility into the development process I have focused on
>automated evaluation of markup accessibility issues. The idea is that if you
>can make a basic markup accessibility check part of other automated tests
>there will be alot less errors discovered at the end of the project. Many of
>the existing tools today are not automatable and require a lot of expertise
>to go understand the result.
>
>For this purpose I am trying to make it possible to integrate Raakt (the
>Ruby Accessibility Analysis Kit)
>[2]<http://www.peterkrantz.com/raakt/wiki/>;into some of the popular
>acceptance testing frameworks.
>
>I would be grateful for your feedback on my ideas. Could this type of basic
>testing be valuable? In your experience, are my observations valid?
>
>[1]: http://www.standards-schmandards.com/2007/rapid-accessibility-feedback/
>[2]: http://www.peterkrantz.com/raakt/wiki/
>
>Thank you for your time.
>
>Regards,
>
>Peter Krantz
>
From: Peter Krantz
Date: Mon, Apr 16 2007 9:10AM
Subject: Re: Bringing accessibility into the development process(request for feedback).
← Previous message | Next message →
Jon,
Thank's for your reply. I am not sure I completely understand the FAE so
forgive me if some of these assumptions are wrong. Some issues I found
developers to have with online tools in general are:
1. They are online meaning that it takes too much time to test a
single page you are developing.
2. They require manual intervention to do the test (which takes time).
3. They typically provide feedback that you have to be able to
interpret to make use of. E.g. some warnings from the FAE may be
irrelevant but it is hard to know if you don't know accessibility.
Is it possible to integrate FAE with functional testing tools such as Watir,
HTMLUnit or Selenium?
What type of user do you see using the FAE?
Regards,
Peter
On 4/16/07, Jon Gunderson < = EMAIL ADDRESS REMOVED = > wrote:
>
> A tool we are developing at the University of Illinois is trying to go
> beyond traditional accessibility checking and providing additional
> evaluation information on the presence of functional accessibility features.
>
>
From: Patrick H. Lauke
Date: Mon, Apr 16 2007 9:30AM
Subject: Re: Bringing accessibility into the developmentprocess (request for feedback).
← Previous message | Next message →
Quoting Peter Krantz < = EMAIL ADDRESS REMOVED = >:
> 2. They require manual intervention to do the test (which takes time).
> 3. They typically provide feedback that you have to be able to
> interpret to make use of. E.g. some warnings from the FAE may be
> irrelevant but it is hard to know if you don't know accessibility.
You're not going to get an automated tool that can tell you if a
resource is accessible or not, on its own. There ALWAYS needs to be
human/manual intervention and review, at least for part of the tests
that can be performed. Any tool that pretends to give you an
authoritive answer without human intervention is lying.
P
--
Patrick H. Lauke
From: tedd
Date: Mon, Apr 16 2007 10:10AM
Subject: Re: Bringing accessibility into the development process (request for feedback).
← Previous message | Next message →
At 5:08 PM +0200 4/16/07, Peter Krantz wrote:
>Jon,
>
>Thank's for your reply. I am not sure I completely understand the FAE so
>forgive me if some of these assumptions are wrong. Some issues I found
>developers to have with online tools in general are:
>
> 1. They are online meaning that it takes too much time to test a
> single page you are developing.
> 2. They require manual intervention to do the test (which takes time).
> 3. They typically provide feedback that you have to be able to
> interpret to make use of. E.g. some warnings from the FAE may be
> irrelevant but it is hard to know if you don't know accessibility.
>
>Is it possible to integrate FAE with functional testing tools such as Watir,
>HTMLUnit or Selenium?
>
>What type of user do you see using the FAE?
>
>Regards,
>
>Peter
Peter:
Not speaking for Jon, but rather as a user of services like theirs,
I'm just a web developer trying to conform to standards as best I can.
I don't see any problems with online checking. Online checking helps
me see problems as I develop my code. I can't imagine any better way
to do this (a topic for another discussion).
As for [1] that's just nonsense. It may take too much time for
developers to fix their errors, but that's not the fault of the test
but rather the ignorance of the developer.
As for [2] again nonsense. It take very little time to test a page --
what are we talking about -- less than a minute? If developers are
concerned about wasting a minute to see where they went wrong, then
they are not concerned about their code, much less accessibility.
Give me a break -- any developer worth his salt is concerned about
his code.
As for [3] knowing what accessibility is, very few developers are
going to fully understand being denied access until it happens to
them. All they can do until then (hopefully never) is to follow
guidelines and learn. That means to know what the barriers are, how
to remove them, and do it -- that's accessibility.
There's no magical cure, no shortcut -- just plain hard work in
learning, understanding, and applying solutions.
And accessibility is something that all of us have to learn -- even
FAE. For example, as was pointed out to me recently in my site, the
color that FAE uses for their links (#0066CC on #FFFFFF) doesn't pass
the contrast test for accessibility.
You see accessibility travels deep and we all are going to have to be
aware of the problems. Even those of us who think we know better --
we all can learn.
As for cost, not that you asked, but contributing another up to 12
percent more customers to any sales base has to be considered
seriously. Accessibility is not one of those "being sensitive to the
needs of the unfortunate" things, but rather a solid and well founded
business decision. It makes dollars as well as sense to be accessible.
Thanks for asking.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
From: Peter Krantz
Date: Mon, Apr 16 2007 10:30AM
Subject: Re: Bringing accessibility into the development process(request for feedback).
← Previous message | Next message →
On 4/16/07, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
> You're not going to get an automated tool that can tell you if a
> resource is accessible or not, on its own. There ALWAYS needs to be
> human/manual intervention and review, at least for part of the tests
> that can be performed. Any tool that pretends to give you an
> authoritive answer without human intervention is lying.
That can be a problem in my opinion. A project typically is staffed with
designers (influencing e.g. color contrast), developers (influencing markup)
and content editors (influencing content). Instead of having one tool that
fits none of these roles I propose that there should be tools that target
each role individually.
Also, the strife for a definitive "Yes! Your page is completely accessible"
does not rule out tools that give you feedback on various parts of
accessibility.
Raakt, for example, targets markup developers by trying to become a part of
the toolsets they already use (functional testing frameworks). Instead of
not using any tool at all I have tried to lower the barrier to at least do
some checking while you are developing.
Regards,
Peter
From: Peter Krantz
Date: Mon, Apr 16 2007 11:10AM
Subject: Re: Bringing accessibility into the development process(request for feedback).
← Previous message | Next message →
On 4/16/07, tedd < = EMAIL ADDRESS REMOVED = > wrote:
>
> Peter:
>
> Not speaking for Jon, but rather as a user of services like theirs,
> I'm just a web developer trying to conform to standards as best I can.
>
> I don't see any problems with online checking. Online checking helps
> me see problems as I develop my code. I can't imagine any better way
> to do this (a topic for another discussion).
>
> As for [1] that's just nonsense. It may take too much time for
> developers to fix their errors, but that's not the fault of the test
> but rather the ignorance of the developer.
Thank you for your feedback. Maybe your experience is from smaller sites
where you didn't employ a test driven approach?. If you have a large
application and work with TDD you want to run all tests as soon as you are
about to check in code (which may happen several times a day). Any
disturbance in this process impacts available development time.
Going through each view combination in your application will require you to
run through the process manually, stopping and sending the resulting HTML to
one of these online validators and then interpret the result. Manually
stepping through just one of the scenarios in an application in a recent
project I participated in took around 20 minutes. That's why many
development projects use an automated test tool like Watir or Selenium.
> As for [2] again nonsense. It take very little time to test a page --
> what are we talking about -- less than a minute? If developers are
> concerned about wasting a minute to see where they went wrong, then
> they are not concerned about their code, much less accessibility.
> Give me a break -- any developer worth his salt is concerned about
> his code.
See above. If you need to run all tests (and interpret the result) for many
pages it will take a lot of time.
There's no magical cure, no shortcut -- just plain hard work in
> learning, understanding, and applying solutions.
That's why I am looking into tools to make it easier for developers. It
shouldn't be hard work to increase basic accessibility. Maybe that's why
many modern software development projects still miss this point?
Regards,
Peter
From: Patrick H. Lauke
Date: Mon, Apr 16 2007 12:20PM
Subject: Re: Bringing accessibility into the development process (request for feedback).
← Previous message | Next message →
Peter Krantz wrote:
> Also, the strife for a definitive "Yes! Your page is completely accessible"
> does not rule out tools that give you feedback on various parts of
> accessibility.
Yes, such a tool would be fine, but the reality is that you CANNOT build
such a tool. That's sadly a fact that you've got to accept. To pick the
simplest of examples, an automated tool can check that you've added an
ALT attribute to your image, but it can't check if the ALT you've put in
is appropriate (which doesn't necessarily mean it needs to reflect its
content, but rather it's a mixture of content and context of the actual
page itself).
For better or worse, there NEEDS to be human intervention and manual
checking.
P
--
Patrick H. Lauke
From: Peter Krantz
Date: Mon, Apr 16 2007 12:40PM
Subject: Re: Bringing accessibility into the development process(request for feedback).
← Previous message | Next message →
On 4/16/07, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
> Peter Krantz wrote:
>
> > Also, the strife for a definitive "Yes! Your page is completely
> accessible"
> > does not rule out tools that give you feedback on various parts of
> > accessibility.
>
> Yes, such a tool would be fine, but the reality is that you CANNOT build
> such a tool.
Not sure I am following you here. Why can't I build a tool that checks some
basic things such as the prescence of an alt attribute?
Maybe you misinterpreted me. I am not arguing that a "complete"
accessibility check doesn't require manual intervention. But if a developer
gets feedback one some basic things such as field labels, alt attributes,
heading structure etc isn't that better than no feedback at all during the
development phase?
Wouldn't that make a thorough accessibility check at the and of a project
less likely to find markup issues (like missing alt attributes)? Which is
the point I am trying to make...
Regards,
Peter
From: Joshue O Connor
Date: Mon, Apr 16 2007 12:50PM
Subject: Re: Bringing accessibility into the development process (request for feedback).
← Previous message | Next message →
Patrick H. Lauke wrote:
> For better or worse, there NEEDS to be human intervention and manual
> checking.
And the day there stops being that need I shall hang up my clogs ;)
Josh
********************************************************************
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: Tim Harshbarger
Date: Mon, Apr 16 2007 2:20PM
Subject: Re: Bringing accessibility into the developmentprocess(request for feedback).
← Previous message | Next message →
Peter,
Yes, there can be some value in automated testing. Your example of the
alt attribute and the label element are good ones. Automated testing
could verify for the existence of an alt attribute and the correct use
of a label element. It may not be able to discern if the alt attribute
contains a good description or if the label is attached to the correct
control, but you may be able to extend your tool to provide feedback to
the developer that allows them to verify if it is the case.
One thing I have learned from someone who used automated tools
extensively is that over time, a developer will start using the tool
less frequently. At least in that specific case, the developer reached
a point where she knew what she was supposed to do and no longer needed
the tool to tell her. In that way, the tool seemed to serve as a
temporary teaching aid.
Some other ways of better integrating accessibility into the development
process might be to include more accessibility decisions in the design
phase and to employ more reusable components in the user interface.
For example, all the alternative text descriptions could be written
during the design phase. Also, design is the best place to make
decisions on how the task will flow and what keystrokes users will need
to use to perform tasks.
Additionally, creating accessible reusable UI components and UI patterns
may assist your efforts, since you would basically address the
accessibility issues for that component once and then deploying it
multiple times.
Tim
From: tedd
Date: Mon, Apr 16 2007 3:10PM
Subject: Re: Bringing accessibility into the development process (request for feedback).
← Previous message | Next message →
At 7:00 PM +0200 4/16/07, Peter Krantz wrote:
>Thank you for your feedback. Maybe your experience is from smaller sites
>where you didn't employ a test driven approach?.
Peter:
I don't know what a large site is -- 100 pages, 200 pages, what?
The maximum site I've worked on had between 50 to 100 end-user "on
the fly" customized pages with calendar, news, and some other
functions -- I don't know if that qualifies or not.
However, large sites like that don't present much more of a problem
than a typical three page site in terms of accessibility -- provided
-- you are organized. The standardization of form and content
(layout) throughout the site coupled with a good navigational scheme
and focused css provides an excellent foundation for generating site
of any size -- it's just variations of a theme.
>If you have a large
>application and work with TDD you want to run all tests as soon as you are
>about to check in code (which may happen several times a day). Any
>disturbance in this process impacts available development time.
Understood, but understanding and applying "good practice" basics
when developing code will certainly cut development time. The real
cost in development time is spent fixing deviations from good
practice, no?
>Going through each view combination in your application will require you to
>run through the process manually, stopping and sending the resulting HTML to
>one of these online validators and then interpret the result. Manually
>stepping through just one of the scenarios in an application in a recent
>project I participated in took around 20 minutes.
That's for the first time. If you learn, then the next time it will be less.
>That's why many development projects use an automated test tool like
>Watir or Selenium.
I don't know those tools, so I can not comment specifically. However,
perhaps reliance on tools like that are part of the problem. I don't
think all of this can be automated -- at least not yet.
Keep in mind, that application developers to automate web development
created WYSIWYG editors that lead (or at least contributed greatly)
to the wide spread table abuse we have now.
>See above. If you need to run all tests (and interpret the result) for many
>pages it will take a lot of time.
If you use good practice in coding, then the test for many pages
should be no more than a test for the number of layouts you're using.
Every page of your web site (except content) should not be unique,
are they? If so, I would wonder why -- that's like like publishing a
book where every page has a different layout.
My advice would be to create internal standards for text, graphics,
links, forms and have your developers work from those standards. This
is not rocket science, it's just adapting good practice standards.
>There's no magical cure, no shortcut -- just plain hard work in
> > learning, understanding, and applying solutions.
>
>That's why I am looking into tools to make it easier for developers. It
>shouldn't be hard work to increase basic accessibility. Maybe that's why
>many modern software development projects still miss this point?
The hard work I'm referring to is learning the problems, figuring out
what to do, and then applying what you've learned. After knowing it
becomes simperer and easier. It's like learning anything -- like css
-- once you see what it does, then it becomes second nature to apply
it.
I am sure that you can put together a list of guidelines of things to
look for. There are even several books on the subject -- the two that
I purchased are "Building Accessible Websites" by Joe Clark and
"Accessible Web Sites by Thacher et al. Those will give you a good
introduction.
Of course, you could always out-source some of that work to me. :-)
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
From: tedd
Date: Mon, Apr 16 2007 3:20PM
Subject: Re: Bringing accessibility into the development process(request for feedback).
← Previous message | Next message →
At 1:13 PM -0700 4/16/07, Tim Harshbarger wrote:
>Peter,
>
>Yes, there can be some value in automated testing. Your example of the
>alt attribute and the label element are good ones. Automated testing
>could verify for the existence of an alt attribute and the correct use
>of a label element. It may not be able to discern if the alt attribute
>contains a good description or if the label is attached to the correct
>control, but you may be able to extend your tool to provide feedback to
>the developer that allows them to verify if it is the case.
>
>One thing I have learned from someone who used automated tools
>extensively is that over time, a developer will start using the tool
>less frequently. At least in that specific case, the developer reached
>a point where she knew what she was supposed to do and no longer needed
>the tool to tell her. In that way, the tool seemed to serve as a
>temporary teaching aid.
>
>Some other ways of better integrating accessibility into the development
>process might be to include more accessibility decisions in the design
>phase and to employ more reusable components in the user interface.
>
>For example, all the alternative text descriptions could be written
>during the design phase. Also, design is the best place to make
>decisions on how the task will flow and what keystrokes users will need
>to use to perform tasks.
>
>Additionally, creating accessible reusable UI components and UI patterns
>may assist your efforts, since you would basically address the
>accessibility issues for that component once and then deploying it
>multiple times.
>
>Tim
Tim:
Five bingo's in row -- way to go. :-)
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
From: Jon Gunderson
Date: Mon, Apr 16 2007 8:30PM
Subject: Re: Bringing accessibility into the development process (request for feedback).
← Previous message | Next message →
Peter,
One of the features of FAE is that the feedback is based on best practices rules and it tells the user what to do to fix the problem. So there no "manual" checks like in other systems. In the next release there will be even better developer feedback on what needs to be change din the markup to pass a rule. There are few warnings on a few rules.
You can get an FAE report directly from Firefox using the Firefox Accessibility Extension:
http://firefox.cita.uiuc.edu
Accessibility -> Tools -> FAE Report
This report actually sends the Firefox DOM representation of the document to FAE so it can check the accessibility of dynamically generated web content.
Please try it and let us know what you think.
Jon
---- Original message ----
>Date: Mon, 16 Apr 2007 17:08:09 +0200
>From: "Peter Krantz" < = EMAIL ADDRESS REMOVED = >
>Subject: Re: [WebAIM] Bringing accessibility into the development process (request for feedback).
>To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>
>Jon,
>
>Thank's for your reply. I am not sure I completely understand the FAE so
>forgive me if some of these assumptions are wrong. Some issues I found
>developers to have with online tools in general are:
>
> 1. They are online meaning that it takes too much time to test a
> single page you are developing.
> 2. They require manual intervention to do the test (which takes time).
> 3. They typically provide feedback that you have to be able to
> interpret to make use of. E.g. some warnings from the FAE may be
> irrelevant but it is hard to know if you don't know accessibility.
>
>Is it possible to integrate FAE with functional testing tools such as Watir,
>HTMLUnit or Selenium?
>
>What type of user do you see using the FAE?
>
>Regards,
>
>Peter
>
>
>On 4/16/07, Jon Gunderson < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> A tool we are developing at the University of Illinois is trying to go
>> beyond traditional accessibility checking and providing additional
>> evaluation information on the presence of functional accessibility features.
>>
>>
>
From: smithj7
Date: Sat, Apr 21 2007 5:50AM
Subject: Re: Bringing accessibility into thedevelopmentprocess (request for feedback).
← Previous message | Next message →
I agree with Patrick regarding the need for user input. For example, I
had a form on our site (note wasn't used much - been there 10 years) and
it was html that of course past ever accessiblity and evaluation test.
However, our users got used to being able to download a form (rich text
format) and complete it using their computers. The html form was not
usable for this.
From: smithj7
Date: Sat, Apr 21 2007 6:30AM
Subject: Re: Bringing accessibility into the developmentprocess(request for feedback).
← Previous message | No next message
Peter I'm sorry its taken so long to reply. I really enjoyed your
article: Bringing Accessibility into the Development Process. I am
drafting a "policy" for our web content folks. I forgot the importance
of including design folks. In our organization designers are usually
part of the Communications department. They like our content folks know
little about the assessible web design. The small number of web
developers end up spending a lot of time trying to keep the multiple of
folks in their chain of command happy even though they have had 508
training. Accessiblity needs to be everyones concern.
Your tool would definitely help our web developers meet major coding
problems. Like you said on the main page of the tool, it does not
require accessiblity knowledge. The coding folks would know what the
report means. But tools like FAE (mentioned in another email) are still
needed to get the requirements. I definitely will try to get our web
developers to use your tool as a first check. It is quick and easily
understood by coders. If we had a nice clean accessible template, then
it might be the only step needed.
FYI here is the check from your report of a NEWLY designed DOE page
http://www.flbog.org/ Below it is a text version of what FAE provides.
At this point in time our web develop team would not understand the FAE
report, but understand what you are doing. But if they fixed only the
items in yours all requirements wouldn't be met. BTW, I have several of
our web folks using tools that are to internet explorer to better
understand reports like FAE. (e.g. WAVE) I am probaly the only web
person that uses FOX FIRE and I use that one a lot. WAVE is difficult
for me to understand. (I have a learning disablity and can't remember
the icons but some of the web folks are learning to like WAVE.) Our
state provides hisoft (cythia says) licenses, but for some reason the
web folks in our Department aren't using it.
missing_heading
Missing first level heading (h1). Provide at least one first level
heading describing document content.
field_missing_label
A field (with id/name 'Text2') is missing a corresponding label element.
Make sure a label exists for all visible fields.
missing_alt
Missing alt attribute for image (with src
'/images/banner/pixels_yellow.gif').
missing_alt
Missing alt attribute for image (with src
'/images/banner/pixels_red.gif').
missing_alt
Missing alt attribute for image (with src
'/images/banner/pixels_yellow.gif').
missing_alt
Missing alt attribute for image (with src
'/images/banner/pixels_red.gif').
missing_alt
Missing alt attribute for image (with src '/images/stripes.gif').
missing_alt
Missing alt attribute for image (with src
'/images/FrontPagePhotos/1.jpg').
missing_alt
Missing alt attribute for image (with src '/images/stripes.gif').
missing_alt
Missing alt attribute for image (with src
'chancellor/images/bg_rosenburg.jpg').
has_nested_tables
You have one or more nested tables.
missing_semantics
You have used font, font, font, b, b, b, b, b, b, b, b for visual
formatting. Use CSS instead.
missing_lang_info
Document language information is missing. Use the lang attribute on the
html element.
missing_th
Missing table headings (th) for table #1.
missing_th
Missing table headings (th) for table #2.
missing_th
Missing table headings (th) for table #3.
missing_th
Missing table headings (th) for table #4.
missing_th
Missing table headings (th) for table #5.
missing_th
Missing table headings (th) for table #6.
missing_th
Missing table headings (th) for table #7.
missing_th
Missing table headings (th) for table #8.
missing_th
Missing table headings (th) for table #9.
missing_th
Missing table headings (th) for table #10.
missing_th
Missing table headings (th) for table #11.
missing_th
Missing table headings (th) for table #12.
missing_th
Missing table headings (th) for table #13.
missing_th
Missing table headings (th) for table #14.
missing_th
Missing table headings (th) for table #15.
missing_th
Missing table headings (th) for table #16.
ambiguous_link_text
One or more links have the same link text ('Public Universities'). Make
sure each link is unambiguous.
Test Evaluation Summaries in HTML Best Practices Main Categories Status
1 % Pass % Warn % Fail
Navigation & Orientation Not Implemented 12 0 87
Text Equivalents Partially Implemented 0 50 50
Scripting Not Applicable 0 0 0
Styling Not Implemented 0 0 100
HTML Standards Not Implemented 0 33 66
Detail information of these categories.
Test Evaluation Percentages in HTML Best Practices Subcategories
First item percent Pass
Second percent Warning
Third percent fail
Last item percent N/A (there is a number)
Category - Navigation & Orientation
Document Title 33 0 66 0
Navigation Bars 0 0 0 100
Section Headings 0 0 100 0
Form Controls 0 0 100 0
Document Linearization 0 0 100 0
Data Tables 0 0 0 100
Frames 0 0 0 100
Access Keys 0 0 0 100
Category - Text Equivalents
Images 0 50 50 0
Embedded Objects 0 0 0 100
Category - Scripting
Device Independence 0 0 0 100
Styling
Text Styling 0 0 100 0
Content Positioning 0 0 100 0
Images 0 0 100 0
Category - HTML Standards
W3C Specifications 0 33 66 0