<a href="https://bytes.com/topic/html-css/answers/154773-accessibility-site-check">Accessibility: Site check

On 7 Apr 2005 13:32:03 -0700, ri**************@hotmail.com wrote:

If anyone's got the time I'd really appreciate any feedback on the
accessibility of this site:
http://www.cata.co.uk/_index.asp

What's with the leading "_" ? Just for beta testing?
It's almost there. In many ways you've clearly put a lot of technical
effort into getting things right,

Then completely bolloxed it by colour choices on the homepage!
There's no contrast - I can't read it, even if I wear the good
eyeballs.

And the "high contrast" version is even worse - the font choices (like
so many) are unreadable when placed with light text on black. Why do
you think solid black backgrounds are a good idea here ? Decades of
VDU ergonomics says otherwise.

I _HATE_ this content / stylesheet switching business (on any site).
Accessibility is about making the content work, not giving a link to a
second-guess at doing it right, through a link that your users
probably can't find.

A link to "Notes for enhanced access" isn't so bad, as your"We have added a number of features to make sure the website is accessible to blind and partially sighted users." text has it. But you really don't need to make some "magic
stylesheet" that changes the display.
The site is unprintable. Doesn't combining media="screen" and
title="default" give you a hint that something's amiss?

Give it a default stylesheet that works (basically the one you already
have for "screen"). Give it a print stylesheet (if you wish) that can
optimise some of the printing issues. I've never yet seen any good
need for a specific "screen" stylesheet.
I'm wary of the huge menu. Screen readers will be gabbling away for a
week. This is sensible on the homepage, but I'd be wary of doing it on
every page. Personally I give the full depth for the "local" menu
tree, but only the upper levels for the more distant parts of the
site. Switch them off with CSS visibility:hidden; and turn them back
on dynamically if JavaScript is available. Non-JS nav just gets the
local version (and one extra click for long nav paths)
Unadorned <span>s concern me. If the mark-up is worth putting in, it's
worth subclassing or titling it. CSS that relies on an unclassed
<span> as a child of a known element, in contrast to a classed <span>
is a pain for maintenance.

Even more so, untitled <div>s (where they're semantically structuring
content) and <ul>s.
<div class="bump"><h2>Open</h2></div>
<p>Open from Easter to the end of October</p>

<p>Weekdays 10 <acronym title="in the morning">a.m.</acronym> - 6 <acronym title="in the afternoon">p.m.</acronym><br />
Last admission 5.00 <acronym title="in the afternoon">p.m.</acronym> </p>
<p>Closed Saturdays and Sundays </p>
</div>
This could usefully gain a title of "Opening times". A title
attribute on the higher levels of <h*> elements isn't a bad thing
either - treat them like alt text on images, as a replacement for the
whole element. Although "Open" isn't a bad title in an overall
two-dimensional context, if you're reading (or listening) in a
strictly serial manner, the title with _the full context in one
phrase_ is much more accessible. Similarly title on <a> elements is
worth the effort.

I hate markup like this:

<div class="header">[<a href="...url..." >...stuff...</a>]

That's a list. It's even a menu if you like (I'd mark it up with
<menu> ) Give it some semantically sensible markup to emphasise
this, don't just do this flat-text business that only shows its real
structure when you render it.

"[" as a separator in menu items belongs in a CSS :before {content()}
rule, not in the main document.

Give the menu <div> a title too.
<img> needs title attributes as well as alt. Remember FireFox.
You don't need to class <li>s <li class="level2"> Put the class on the parent <ul>. I do like to class the <ul>s though,
because "counting down the tree" for nested <ul>s is a pain for the
CSS selectors.
I'm always distrustful of repeated <br /> elements, let alone        
<meta http-equiv="Content-Type" ... > can only ever cause trouble.
Inlining a style="border-left-width: 1px;" on the first <li> in a
list is a pain for future content management. Put it in the CSS and
use a class of "first element" if you have to (one day the CSS
selectors will let us do this automatically)

These days, don't hand-write HTML that you couldn't auto-generate. If
you use inline CSS like this, it would find itself hard-coded as the
specifics of a CSS implementation (border-left-width: 1px) inside a
loop of some poor unfortunate CMS. That'll bite you in the future.

<strong>Telephone:</strong> 0<span class="tiny"> </span>1<span class="tiny"> </span>7<span class="tiny"> What's with the funny digit spacing control ?

<span class="hidden">.</span> this worries me

<a name="content" id="content"></a>

From the HTML 4 TR
: > Note. User agents should be able to find anchors created by empty A elements,
: > but some fail to do so. For example, some user agents may not find the
: > "empty-anchor" in the following HTML fragment:
Overall I like it. A good and thorough effort. If only I could read
the text on the homepage - I almost abandoned the site within seconds,
just because of that.

Jul 24 '05 #7

On Thu, 07 Apr 2005 19:05:24 +0000, Chris Applegate
<Ch************@cwru.edu> wrote:

Last, but not least, if you're going to be so pedantic as to expand the
abbreviations A.M. and P.M., do it right. It's ante meridiem and post
meridiem.

I disagree. This isn't a dictionary, it's a guidebook with opening
times. If someone doesn't know what they mean (whether by ignorance
or lack of context), then they don't need a latin lesson.

Jul 24 '05 #8

Stan Brown

"" wrote in comp.infosystems.www.authoring.html:

Hi,
If anyone's got the time I'd really appreciate any feedback on the
accessibility of this site:

You've posted this at least three times in at least two different
newsgroups that I've seen so far.

What is the accepted way to share a message across multiple
newsgroups?
http://smjg.port5.com/faqs/usenet/xpost.html

--

Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/

Jul 24 '05 #9

Eric Bohlman

Andy Dingley <di*****@codesmiths.com> wrote in
news:0m********************************@4ax.com:

<strong>Telephone:</strong> 0<span class="tiny"> </span>1<span
class="tiny"> </span>7<span class="tiny">

What's with the funny digit spacing control ?

I'm guessing that it's a (probably clumsy) attempt to get screen readers to
read out the phone number as a digit string rather than a quantity (e.g.
read my area code as "seven seven three" rather than "seven hundred
seventy-three").

Jul 24 '05 #10

richard_quick_uk

It is.

I've been experimenting to see what various screen readers do, but some
of those that don't read straight from the DOM (e.g. Dolphin) seem to
ignore aural CSS, such as:
speak-numeral: digits;

and so still read the telephone number as figure, reather than a series
of digits.

If anyone can think of a better way of doing this I'd be happy to uear
it, as this is a mjor pain in the backside
to do...

Jul 24 '05 #11

Richard Quick

> Phone numbers have spaces between the digits in Lynx. They look alright

in Firefox. That's because you're placing each number within a span
element, and Lynx handles spans differently than Gecko. Was that to
assist with screen readers? Kind of clever, if it works.
That was why I did it, and it seems to work.
Last, but not least, if you're going to be so pedantic as to expand the
abbreviations A.M. and P.M., do it right. It's ante meridiem and post
meridiem. You might need a lang attribute to specify that those are in
Latin. Pedantry is encouraged, but must always be carried to its logical
conclusion.

I wasn't putting them in to be pedantic, I was putting them in to
assit blind users.

Screen readers and voice browsers tend to take a guess at the
pronunciations of words, and I doubt they've all got separate phonetic
rules for Latin, so I couldn't guarantee that the latin ante merideum
would be pronounced correctly.

Besides, as well as blindesss accessibility encompases learning
disabilities, and I woudn't guarantee everyone kew what ante meridiem
meant. In the morning is safer and friendlier, I think.

Jul 24 '05 #12

Richard Quick

Andy Dingley <di*****@codesmiths.com> wrote in message news:<0m********************************@4ax.com>. ..

On 7 Apr 2005 13:32:03 -0700, ri**************@hotmail.com wrote:
If anyone's got the time I'd really appreciate any feedback on the
accessibility of this site:
http://www.cata.co.uk/_index.asp

What's with the leading "_" ? Just for beta testing?

Yeah.

It's almost there. In many ways you've clearly put a lot of technical
effort into getting things right,

Then completely bolloxed it by colour choices on the homepage!
There's no contrast - I can't read it, even if I wear the good
eyeballs.
I agree 100%.

Unfortunatly I didn't design the site, I was just trying to make it as
accessible as possible (see http://www.cata.co.uk for the original).

I am going to try to get the client to agree to changing the homepage
colour - as it's not just disabled people who would struggle with the
page - I've got 20/20 vision and even I find it unreadable.

And the "high contrast" version is even worse - the font choices (like
so many) are unreadable when placed with light text on black. Why do
you think solid black backgrounds are a good idea here ? Decades of
VDU ergonomics says otherwise.
My understanding is that studies have shown yellow on black to be the
most legible colour combinations.
I _HATE_ this content / stylesheet switching business (on any site).
Accessibility is about making the content work, not giving a link to a
second-guess at doing it right, through a link that your users
probably can't find.
Sorry, but I've got disagree with you on this one. Web accessibility
is about ensuring people with disabilities have access to the
information and services on a website. I've endeavoured to make the
default version as accessible as possible, while working within
commercial confines. However, many diadbled people I've met have
older computers, and therefore I needed to put in a catch-all
formattign free version to ensure that the site was definitly
accessible.

Also, the 'blind and partially sighted users' link is the first link
on the page, and is therfore the first thing that would be read out by
a sreeen reader or aural browser, so I think that a blind user would
be able to find it.

A link to "Notes for enhanced access" isn't so bad, as your
"We have added a number of features to make sure the website is accessible to blind and partially sighted users." text has it. But you really don't need to make some "magic
stylesheet" that changes the display.
The site is unprintable. Doesn't combining media="screen" and
title="default" give you a hint that something's amiss?

Give it a default stylesheet that works (basically the one you already
have for "screen"). Give it a print stylesheet (if you wish) that can
optimise some of the printing issues. I've never yet seen any good
need for a specific "screen" stylesheet.
I'm wary of the huge menu. Screen readers will be gabbling away for a
week. This is sensible on the homepage, but I'd be wary of doing it on
every page. Personally I give the full depth for the "local" menu
tree, but only the upper levels for the more distant parts of the
site. Switch them off with CSS visibility:hidden; and turn them back
on dynamically if JavaScript is available. Non-JS nav just gets the
local version (and one extra click for long nav paths)

On the text-only version, there is a skip navigation link (which in
the graphic version is in a hidden div). Jaws shouild also pick this
up in grpahic mode, as it reads stright from the DOM.
Unadorned <span>s concern me. If the mark-up is worth putting in, it's
worth subclassing or titling it. CSS that relies on an unclassed
<span> as a child of a known element, in contrast to a classed <span>
is a pain for maintenance.

Even more so, untitled <div>s (where they're semantically structuring
content) and <ul>s.
<div class="bump"><h2>Open</h2></div>
<p>Open from Easter to the end of October</p>

<p>Weekdays 10 <acronym title="in the morning">a.m.</acronym> - 6 <acronym title="in the afternoon">p.m.</acronym><br />
Last admission 5.00 <acronym title="in the afternoon">p.m.</acronym> </p>
<p>Closed Saturdays and Sundays </p>
</div>
This could usefully gain a title of "Opening times". A title
attribute on the higher levels of <h*> elements isn't a bad thing
either - treat them like alt text on images, as a replacement for the
whole element. Although "Open" isn't a bad title in an overall
two-dimensional context, if you're reading (or listening) in a
strictly serial manner, the title with _the full context in one
phrase_ is much more accessible. Similarly title on <a> elements is
worth the effort.

Thanks for the idea, I'll do this.
I hate markup like this:

<div class="header">[<a href="...url..." >...stuff...</a>]

That's a list. It's even a menu if you like (I'd mark it up with
<menu> ) Give it some semantically sensible markup to emphasise
this, don't just do this flat-text business that only shows its real
structure when you render it.

"[" as a separator in menu items belongs in a CSS :before {content()}
rule, not in the main document.
Woudn't work with CSS disabled, which I need it to. It's to separate
the links (see below re: <div class="hidden">.</div>
Give the menu <div> a title too.
<img> needs title attributes as well as alt. Remember FireFox.
Does this affect the accessibility for somone using a screen reader
and firefox?

You don't need to class <li>s
<li class="level2"> Put the class on the parent <ul>. I do like to class the <ul>s though,
because "counting down the tree" for nested <ul>s is a pain for the
CSS selectors.
I'm always distrustful of repeated <br /> elements, let alone
       
Yeah, I know, just done for speed of coding.
<meta http-equiv="Content-Type" ... >

can only ever cause trouble.
Inlining a style="border-left-width: 1px;" on the first <li> in a
list is a pain for future content management. Put it in the CSS and
use a class of "first element" if you have to (one day the CSS
selectors will let us do this automatically)

These days, don't hand-write HTML that you couldn't auto-generate. If
you use inline CSS like this, it would find itself hard-coded as the
specifics of a CSS implementation (border-left-width: 1px) inside a
loop of some poor unfortunate CMS. That'll bite you in the future.

It's all drawn in from an include file using ASP. So from a site
management point of view it's not a problem. But I take your point.

<strong>Telephone:</strong> 0<span class="tiny"> </span>1<span class="tiny"> </span>7<span class="tiny">

What's with the funny digit spacing control ?

It's so all screen readers will read the phone numbers as digits, not
large numbers (eg. one thousand, seven hundred and thirty six).

<span class="hidden">.</span> this worries me

It's done because some aural browsers treat consecutive links as one
long link.

<a name="content" id="content"></a>

From the HTML 4 TR
: > Note. User agents should be able to find anchors created by empty A elements,
: > but some fail to do so. For example, some user agents may not find the
: > "empty-anchor" in the following HTML fragment:
Overall I like it. A good and thorough effort. If only I could read
the text on the homepage - I almost abandoned the site within seconds,
just because of that.

Jul 24 '05 #13

Harlan Messinger

ri**************@hotmail.com wrote:

Hi,
If anyone's got the time I'd really appreciate any feedback on the
accessibility of this site:
http://www.cata.co.uk/_index.a*sp
I've just re-programmed it to try and make it as accessible as
possible, and it would be really good to get some feedback, especially
from anybody using assitive technology.

My vision is good and *I* find it difficult to read your orange letters
on the mustard background and white letters on the orange background. I
can't imagine how bad it would be for people with less than complete
visual acuity. This is ironic considering how much attention you've
otherwise devoted to accessibility. Yes, you do offer a high-contrast
version, but it's not as attractive, and simply choosing a more readable
color combination on the regular version of your pages would prevent
many people from needing to resort to an alternate version.

Jul 24 '05 #14

jake

In message <11**********************@g14g2000cwa.googlegroups .com>,
ri**************@hotmail.com writes

Hi,
If anyone's got the time I'd really appreciate any feedback on the
accessibility of this site:
http://www.cata.co.uk/_index.a*sp
I've just re-programmed it to try and make it as accessible as
possible, and it would be really good to get some feedback, especially
from anybody using assitive technology.
Thanks,
Richard

Thoughts:

(1) { display:none;} is honoured by most
screen-readers/talking-browsers. This means that your 'skip navigation'
link will not be spoken. The latest version of JFW will speak it (so I'm
told), but that's about it.

One of the better ways is to locate the text out of the viewport
e.g. Use CSS to position the text waaaay over there ------------->

Using a one-pixel transparent .gif as the link is another way.

(2) Coding the telephone numbers would be a bit simpler like this:

<span class="spell>1 2 3 4 5 6</spell>

..spell { letter-spacing : -0.15em; }

(3) There is nothing to be gained by coding a.m. and p.m. as <acronym>
-- which is wrong anyway, as they're <abbr>.

Come to think of it, a lot of your acronyms should be abbreviations.

(4) There's only a need to mark up the first occurrence of <acronym> or
<abbr> on a page.

(5) Not all readers use a different voice when announcing an <img>, so
it's nice to use a prefix in the alternative text such as PHOTO: IMAGE:
GRAPHIC:, etc.

(6) Important. Try reading your text, but only pausing/stopping where
you see a punctuation mark. If you don't see a punctuation mark, the
odds are that the reader will just keep on reading, making sentences run
into one another.
e.g. Your 'admission charges' section.

(7) Disable any link in a menu that points to itself.
e.g. On the 'Industrial Heritage' page, disable the 'Industrial
Heritage' link.
regards

--
Jake

Jul 24 '05 #15

Did you try testing at
<URL:http://webxact.watchfire.com/ScanForm.aspx>? Since this is
not a U.S. site, ignore the Section 508 guidelines and select one
of the WCAGs.

--

David E. Ross
<URL:http://www.rossde.com/>

I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <URL:http://www.mozilla.org/>.

Jul 24 '05 #16

kchayka

David Ross wrote:

Did you try testing at
<URL:http://webxact.watchfire.com/ScanForm.aspx>?

FYI, Bobby should not be used for any kind of real quality evaluation. I
wouldn't use it for anything more than a cursory check for glaring
accessibility issues.

Bobby's recommendations can be either terribly misleading or outright
wrong. It can report both false negatives and false positives, so don't
take it at its word.

I think Yukka or somebody wrote a good evaluation of Bobby and other
like services...

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.

Jul 24 '05 #17

On Fri, 8 Apr 2005, jake wrote:

Come to think of it, a lot of your acronyms should be abbreviations.

I'd support that: it really would be much nicer if the term "acronym"
was reserved for its technically accurate meaning (a pronounceable
word formed from the initials or initial parts of other words), rather
than the sloppy usage which has developed to cover initialisms and
more (a bad example is even found in the HTML4 specification, where it
offers "F.B.I.", complete with the dots, as one of its examples of an
acronym, gorblimey).

However, the OP should be aware that MessIE does not implement <abbr>,
so if you want to not only supply the correct markup, but also make
things work with that piece of s...oftware too, you'll need something
like this

<span title="ante meridiem"><abbr
title="ante meridiem">a.m</abbr></span>

to cover all the bases. Rather OTT for casual abbreviations - perhaps
best reserved for stuff that's of critical importance to the content.

Jul 24 '05 #18

On Fri, 8 Apr 2005, kchayka wrote:

Bobby's recommendations can be either terribly misleading or
outright wrong. It can report both false negatives and false
positives, so don't take it at its word.

To put it another way: the WAI guidelines consist of both objective
and subjective tests. Both of them can be important to accessibility:
rote observance of the objective tests without any reference to
subjective criteria can even be worse than doing nothing at all -
leading to abuses such as <img alt="for layout only" ...>

Bobby does its best to apply the objective tests, and to call
attention to areas where subjective assessment would likely be needed.
My experience has been that it gets the objective tests correct, with
only rare exceptions. But mere formal compliance with the objective
WAI criteria is no way to make an accessible web page - far from it.

In conclusion, Bobby is doing pretty much what it set out to do (which
isn't so very different in principle from other accessibility
checkers, albeit others have various distinctive features - such as
the possibility of producing a detailed audit report which includes
the author's justifications for various choices made - hi Nick); but
any claims that *any* mere program could be a final arbiter of
accessibility would be inappropriate, and appeal only to suits and
bean-counters.

Jul 24 '05 #19

Philip Ronan

jake wrote:

(1) { display:none;} is honoured by most
screen-readers/talking-browsers. This means that your 'skip navigation'
link will not be spoken. The latest version of JFW will speak it (so I'm
told), but that's about it.

One of the better ways is to locate the text out of the viewport
e.g. Use CSS to position the text waaaay over there ------------->

Using a one-pixel transparent .gif as the link is another way.

Surely it would make more sense to have a "@media aural" stylesheet with
{ display: block; } in it somewhere?

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

Jul 24 '05 #20

Steve Pugh

Philip Ronan <in*****@invalid.invalid> wrote:

jake wrote:
(1) { display:none;} is honoured by most
screen-readers/talking-browsers. This means that your 'skip navigation'
link will not be spoken. The latest version of JFW will speak it (so I'm
told), but that's about it.

One of the better ways is to locate the text out of the viewport
e.g. Use CSS to position the text waaaay over there ------------->

Using a one-pixel transparent .gif as the link is another way.

Surely it would make more sense to have a "@media aural" stylesheet with
{ display: block; } in it somewhere?

In theory that would work for aural browsers. (In theory...)

But screen readers are more widely used that aural browsers. Screen
readers read what's on the screen and hence use media="screen" (they
might well use media="aural" as well but I'm not sure if any currently
do).

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

Jul 24 '05 #21

jake

In message <BE********************@invalid.invalid>, Philip Ronan
<in*****@invalid.invalid> writes

jake wrote:
(1) { display:none;} is honoured by most
screen-readers/talking-browsers. This means that your 'skip navigation'
link will not be spoken. The latest version of JFW will speak it (so I'm
told), but that's about it.

One of the better ways is to locate the text out of the viewport
e.g. Use CSS to position the text waaaay over there ------------->

Using a one-pixel transparent .gif as the link is another way.

Surely it would make more sense to have a "@media aural" stylesheet with
{ display: block; } in it somewhere?

So far as I am aware, Emacspeak (running on Linux) is the only reader
that takes any notice of an aural stylesheet.

regards.

--
Jake

Jul 24 '05 #22

kchayka

Alan J. Flavell wrote:

On Fri, 8 Apr 2005, kchayka wrote:
Bobby's recommendations can be either terribly misleading or
outright wrong.
My experience has been that it gets the objective tests correct, with
only rare exceptions. But mere formal compliance with the objective
WAI criteria is no way to make an accessible web page - far from it.

I consider that falling into the "misleading" category. :)
any claims that *any* mere program could be a final arbiter of
accessibility would be inappropriate, and appeal only to suits and
bean-counters.

It's unfortunate that so many people think if Bobby reports a thumbs up,
the page must be accessible, though I don't see so many "Bobby Approved"
icons on web pages as I used to. Maybe that's a sign, I dunno.

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.

Jul 24 '05 #23

On 8 Apr 2005 02:53:59 -0700, ri**************@hotmail.com (Richard
Quick) wrote:

I am going to try to get the client to agree to changing the homepage
colour - as it's not just disabled people who would struggle with the
page - I've got 20/20 vision and even I find it unreadable.
That explains a lot.
My understanding is that studies have shown yellow on black to be the
most legible colour combinations.
Then that's obsolete. The "yellow on black" studies were an artefact
of the late '80s, dealing with monochrome displays, a choice of white,
green (P31) or brown (P15) phosphors and most importantly, text-only
displays. Much of this was due to the prolonged persistence shown by
the P31 green phosphors.

The problem is that now we're dealing with high resolution screens. I
don't like your hardcore industrial "yellow on black" colours and the
studies referred to light brown on very dark brown, but the real
difference is that the main bars of the high-res font you're using are
simply too thin to be visible against such a solid background. A
suitable choice of font would vastly improve the "high contrast"
display, even with the current colours.

Sorry, but I've got disagree with you on this one. Web accessibility
is about ensuring people with disabilities have access to the
information and services on a website.
Agreed - but if you can do this, why offer a "lesser" version as the
default stylesheet ? The thing about CSS is that the default can
offer every good facility that the "accessible" stylesheet can. There
are features such as font sizing, but these are controlled by local
settings subsidiary to the stylesheet, not as an alternative to the
default.
therefore I needed to put in a catch-all formattign free version

You just don't need to - if CSS isn't supported, then it goes away of
its own accord.

"[" as a separator in menu items belongs in a CSS :before {content()}
rule, not in the main document.

Woudn't work with CSS disabled, which I need it to. It's to separate
the links (see below re: <div class="hidden">.</div>

It works fine if the content is authored as an explicit list, rather
than an inline text stream.

These days, don't hand-write HTML that you couldn't auto-generate. If
you use inline CSS like this, it would find itself hard-coded as the
specifics of a CSS implementation (border-left-width: 1px) inside a
loop of some poor unfortunate CMS. That'll bite you in the future.

It's all drawn in from an include file using ASP. So from a site
management point of view it's not a problem. But I take your point.

My point is that the presentation-dependent binding to 1px (as
distinct to 2px) is embedded deep within some structural logic, not at
the presentational layer. A later author who wishes to change this to
3px must now modify things they have no real business in modifying.

--
Blind drunk - Please ignore all postings I make,
until I sober up enough to notice the .sig file
that has been attached to them.
Thank you.

Jul 24 '05 #24

kchayka wrote:

David Ross wrote:
Did you try testing at
<URL:http://webxact.watchfire.com/ScanForm.aspx>?

FYI, Bobby should not be used for any kind of real quality evaluation. I
wouldn't use it for anything more than a cursory check for glaring
accessibility issues.

Bobby's recommendations can be either terribly misleading or outright
wrong. It can report both false negatives and false positives, so don't
take it at its word.

I think Yukka or somebody wrote a good evaluation of Bobby and other
like services...

I don't use Bobby. I use Watchfire's WebXACT. I don't think Bobby
is maintained; it might no longer be available.

No, such tools are not 100% accurate. When someone asks "Is my Web
page accessible?", however, the page should have already been
tested by some tool, at least as a first filter on that issue.

--

David E. Ross
<URL:http://www.rossde.com/>

I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <URL:http://www.mozilla.org/>.

Jul 24 '05 #25

ri**************@hotmail.com wrote:

Hi,

If anyone's got the time I'd really appreciate any feedback on the
accessibility of this site:

http://www.cata.co.uk/_index.a*sp

I've just re-programmed it to try and make it as accessible as
possible, and it would be really good to get some feedback, especially
from anybody using assitive technology.

Link problem: The mark in the file extension, which looks like a
hyphen, translates as 0xAD (decimal 175), which is not a valid
character in a URL. As is, the page was 404.

I tried changing to 0x96 (decimal 150), which is questionable in a
URL. The page was still 404.

Finally, I eliminated the character.
<URL:http://www.cata.co.uk/_index.asp> is NOT 404.

I have to agree with the others about not having a light-colored
font against a yellow or orange background.

Also, as others noted, the font is quite small; however, my browser
is setup with toolbar buttons that easily change the size. This
highlighted the fact that the page on my PC (800x600 pixel
resolution with an Office toolbar to the right) has a horizontal
(right-left) scrollbar. This scrollbar is present even if I don't
change the font size. In this case, no information is lost if the
viewer does not scroll right-left. However, horizontal scrolling
should be avoided as it is more than a damned annoyance to anyone
with arthritis in the hands or with a motor disability (e.g.,
Parkinson's).

--

David E. Ross
<URL:http://www.rossde.com/>

I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <URL:http://www.mozilla.org/>.

Jul 24 '05 #26

David Ross <no****@nowhere.not> wrote:

I don't use Bobby. I use Watchfire's WebXACT. I don't think Bobby
is maintained; it might no longer be available.

No, such tools are not 100% accurate. When someone asks "Is my Web
page accessible?", however, the page should have already been
tested by some tool, at least as a first filter on that issue.

I beg to differ, Bobby and tools like it create a false illusion of page
accessibility, their use should not be encouraged.

Furthermore a cursory check with webxact of one of my pages shows that
like all the other bots I tested it to fails to pick up correctly used
form labels, and again like the other bots it flags the absence of
"place-holding characters" in form fields as an error. The latter is
simply bad advice taken verbatim from the WAI guidelines.

Not only should authors who are genuinely interested in accessibility
read the actual WAI guidelines, they should read them with a critical
eye, do their own testing and ignore the bad and outdated advice
contained in the WAI guidelines.

--
Spartanicus

Jul 24 '05 #27

On Fri, 8 Apr 2005, David Ross wrote:

Link problem: The mark in the file extension, which looks like a
hyphen, translates as 0xAD (decimal 175),
In other words (knowing that the item was declared as iso-8859-1) a
soft-hyphen. Not exactly a wise move to include in a usenet posting
whose MIME header says it's:

Content-Type: text/plain; charset="iso-8859-1"

but as it was evidently posted to usenet via Google, "caveat postor".
which is not a valid character in a URL.
indeed
I tried changing to 0x96 (decimal 150),

which in iso-8859-1 is a control character, and completely illogical
as a substitute. Thus arguably even *less-valid* than the "not a
valid character in the URL" character which you already rejected.

Jul 24 '05 #28

On Sat, 9 Apr 2005, Spartanicus wrote:

I beg to differ, Bobby and tools like it create a false illusion of
page accessibility, their use should not be encouraged.
You might have a point, but, as I read on, it seems to be for the
wrong reasons.
[...] flags the absence of "place-holding characters" in form fields
as an error. The latter is simply bad advice taken verbatim from the
WAI guidelines.
It seems you agree that the tool is correctly reporting the WAI
guidelines, and thus your disagreement is not with the tool itself,
but with the guidelines which it's implementing.
Not only should authors who are genuinely interested in
accessibility read the actual WAI guidelines, they should read them
with a critical eye, do their own testing and ignore the bad and
outdated advice contained in the WAI guidelines.

In what way does this argue against the use of testing tools as a
principle, though?

The problem IMHO with the uncritical use of testing tools is that they
can apply only *objective* criteria, and are not merely useless but
even counter-productive if applied without any sense of *subjective*
criteria. But that does not for a moment mean that they can't be
useful checking tools - *in the right hands*.

Jul 24 '05 #29

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:

I beg to differ, Bobby and tools like it create a false illusion of
page accessibility, their use should not be encouraged.

You might have a point, but, as I read on, it seems to be for the
wrong reasons.
[...] flags the absence of "place-holding characters" in form fields
as an error. The latter is simply bad advice taken verbatim from the
WAI guidelines.

They are separate points.

--
Spartanicus

Jul 24 '05 #30

On Sat, 9 Apr 2005, Spartanicus wrote:

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:
You might have a point, but, as I read on, it seems to be for the
wrong reasons.
[...] They are separate points.

Oh, I see. Sorry for the mis-reading. You said:

| I beg to differ, Bobby and tools like it create a false illusion
| of page accessibility, their use should not be encouraged.

without offering any specific justification for saying that, and then
you went on with "furthermore" to criticise some points in the WAI
which, as far as I can see, are accurately diagnosed (even if that
particular advice in WAI/1.0 must now be rated as poor) by the tool.

I don't see your reason to give blanket advice against the use of such
tools, which appears to be based only on the fact that they have been
misused too often in practice. I *do* see every reason to encourage
their use only in conjunction with proper understanding of what they
can and can't do - and by no means to treat them as an end in itself.

Jul 24 '05 #31

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:

I *do* see every reason to encourage
their use only in conjunction with proper understanding of what they
can and can't do - and by no means to treat them as an end in itself.

Bots are used by 2 types of people:

1) Those that follow general good authoring guidelines with a cursory
interest in accessibility, for them the bots often *cause* problems if
their advice is acted upon (examples: access keys, the previously
mentioned place holding characters).

2) People who want to claim accessibility without having to do the work.
They make changes to make the reported errors go away, and then they
stick accessibility buttons on every single page, with alt content like
"Checked for accessibility by fudge.org, triple X certified".

Advising someone to use a bot to introduce them to accessibility issues
will at best confuse them, at worst it will cause them to think that
fixing the errors that the bot reports is what it's all about.

They should first read the WAI guidelines, do their own testing,
discard the outdated and/or bogus WAI advice. If that is successfully
accomplished, then the bot can only provide worse indicators.

The bots perform no useful function for those with a decent
understanding of accessibility.

--
Spartanicus

Jul 24 '05 #32

On Sat, 9 Apr 2005, Spartanicus wrote:

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:
I *do* see every reason to encourage
their use only in conjunction with proper understanding of what they
can and can't do - and by no means to treat them as an end in itself.
Bots are used by 2 types of people:

Sorry, I'm not going to do a Spanish Inquisition sketch, but I think I
can say with some confidence that although some users of site checking
tools could be rated to fall under one or other (even both) of your
two headings, those two don't cover all bases by any means.
Advising someone to use a bot to introduce them to accessibility
issues
Excuse me, but you previously said "their use should not be
encouraged", and I disagreed. Now you're saying that they are
unsuitable as an *introduction* to accessibility issues. I agree with
the latter, obviously; but that wasn't what I was disagreeing with
before.
will at best confuse them, at worst it will cause them to think that
fixing the errors that the bot reports is what it's all about.
Isn't that what I've been warning against?
The bots perform no useful function for those with a decent
understanding of accessibility.

In that case it appears my understanding of accessibility must be
indecent, on your scale, because I find them a usable tool - within
the scope of what they can do.

Jul 24 '05 #33

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:

Advising someone to use a bot to introduce them to accessibility
issues

Excuse me, but you previously said "their use should not be
encouraged", and I disagreed. Now you're saying that they are
unsuitable as an *introduction* to accessibility issues. I agree with
the latter, obviously; but that wasn't what I was disagreeing with
before.

I explored possible reasons as to why anyone would advise their usage
since you provided none, I did not attribute that reason to you.

will at best confuse them, at worst it will cause them to think that
fixing the errors that the bot reports is what it's all about.

Isn't that what I've been warning against?
The bots perform no useful function for those with a decent
understanding of accessibility.

In that case it appears my understanding of accessibility must be
indecent, on your scale, because I find them a usable tool - within
the scope of what they can do.

Explain why you think they are useful and maybe then we can continue the
discussion.

--
Spartanicus

Jul 24 '05 #34

Nick Kew

Spartanicus wrote:

Explain why you think they are useful and maybe then we can continue the
discussion.

I can spell, and I understand of English grammar and syntax.
So (being an arrogant ***), I don't use tools like spellcheckers.

Occasionally I make mistakes - typos, or text that is nonsensical
because I chopped the wrong words or line while editing - that a
spellcheck or similar tool would have helped me avoid.

Regarding web accessibility, a tool like AccessValet helps knowledgeable
users to pick up on that kind of mistake.

Likewise, when assessing a third-party site, it helps to generate an
automatic report, then look through it deciding which warnings indicate
something that needs fixing, and which can be safely ignored.

--
Nick Kew

Jul 24 '05 #35

Spartanicus wrote [in part]:

The latter is
simply bad advice taken verbatim from the WAI guidelines.

Not only should authors who are genuinely interested in accessibility
read the actual WAI guidelines, they should read them with a critical
eye, do their own testing and ignore the bad and outdated advice
contained in the WAI guidelines.

I take this (and following comments in this part of the thread) to
say that the WAI guidelines should NOT be considered authoritative
because they are a combination of defective and obsolete. Section
508 of the of the Rehabilitation Act of 1973 (as amended through
1998) is authoritative only for U.S. federal agencies and for those
state and local agencies included under state laws that refer to
Section 508. Is there an authoritative specification of Web
accessibility against which a page can be objectively judged?

--

David E. Ross
<URL:http://www.rossde.com/>

I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <URL:http://www.mozilla.org/>.

Jul 24 '05 #36

Jukka K. Korpela

David Ross <no****@nowhere.not> wrote:

Is there an authoritative specification of Web
accessibility against which a page can be objectively judged?

No, but if you ask yourself _why_ you ask that, you might find
something useful. The crucial question is: do you wish to help people
with disabilities, or do you wish to get a stamp of approval?

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 24 '05 #37

"Jukka K. Korpela" wrote:

David Ross <no****@nowhere.not> wrote:
Is there an authoritative specification of Web
accessibility against which a page can be objectively judged?

No, but if you ask yourself _why_ you ask that, you might find
something useful. The crucial question is: do you wish to help people
with disabilities, or do you wish to get a stamp of approval?

I am trying to be sensitive to persons with disabilities and
handicaps. My mother has macular degeneration and can read only
very large fonts. My brother and two cousins are color-blind.
Before I retired, I worked with someone -- a software developer --
who was a partial quadraplegic, who worked a computer with a stylus
strapped to his hand because he could not use his fingers on a
keyboard or mouse. In a prior job, a coworker -- another software
developer -- was profoundly deaf and was missing fingers, the
result of handling a bomb for the military.

However, beyond the need to wear eyeglasses (farsightedness caused
by age) and an occasional stiffness in my "mouse hand" (too many
years of gripping a mouse as a software test engineer), I do not
have any handicaps affecting my ability to experience the Web.
Thus, I depend upon documented accessibility criteria. I choose to
rely on the WAI guidelines because of the serious thoughts that
went into their development.

Since late October 2003, I have tried to make my personal Web pages
conform to the recommendations of the "Viewable with Any Browser
Campaign". See
<URL:http://www.anybrowser.org/campaign/index.html>. These
recommendations involve not only differences in browser
capabilities but also accessibility. (But, unlike the WAI
guidelines, they are mostly the recommendations of one person.)

Starting in late February 2004, this progressed to making my pages
comply with the HTML 4.01 specification (transitional HTML 4.01).
Over half my pages contain the W3C HTML 4.01 graphic, by which I
assert they are indeed compliant. While compliance does not
guarantee accessibility, a lack of compliance creates a presumption
(rebuttable) of a lack of accessibility.

On occasion, I test my pages using Watchfire's WebXACT. However,
none of my personal pages carry a WAI graphic simply because I do
not choose to test each page that I update.

I also maintain a Web site for a charitable foundation. There, all
of the most recently created or updated pages (since mid-November
2004) do carry the WAI-A WCAG graphic. These have all been tested
with WebXACT. These pages also comply with the HTML 4.01
specification and follow the recommendations of the "Viewable with
Any Browser Campaign". This is not merely a case of "a stamp of
approval". It is instead intended to indicate to the public that
-- unlike many other Web sites -- we care about accessibility. We
want to promote it and encourage others to make their Web sites
accessible.

Accessibility is important, but too few Web developers understand
that. To bring this to the attention of both Web developers and
the public, some public sign (e.g., a WAI graphic) is appropriate.
It is not merely "a stamp of approval".

--

David E. Ross
<URL:http://www.rossde.com/>

I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <URL:http://www.mozilla.org/>.

Jul 24 '05 #38

Tim

On Fri, 08 Apr 2005 12:19:02 -0500,
kchayka <us****@c-net.us> posted:

FYI, Bobby should not be used for any kind of real quality evaluation. I
wouldn't use it for anything more than a cursory check for glaring
accessibility issues.

I tend to agree. I'd use such tools to check whether known mistakes were
made, rather than assume that the page is perfect because they don't find
mistakes.

HTML validators are the same (they have specific abilities). They'll check
whether you've nested your table element properly, but won't tell you if
you've used table headers and table cells for the wrong purposes; and
they'll tell you if you've forgotten to put the closing tag onto an H
element, but can't tell if you're abusing headings to get big text; and so
on...

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

Jul 24 '05 #39

Tim

On Fri, 8 Apr 2005 16:29:27 +0100,
jake <ja**@gododdin.demon.co.uk> posted:

(3) There is nothing to be gained by coding a.m. and p.m. as <acronym>
-- which is wrong anyway, as they're <abbr>.

(4) There's only a need to mark up the first occurrence of <acronym> or
<abbr> on a page.

I'd argue against both points (while agreeing that am and pm are
abbreviations): It's possible for abbreviations to be treated differently
than just text on the page, and I don't just mean hints when you hover the
mouse over them. For instance, it'd take the guesswork out of speech
agents if they knew that <abbr>etc</abbr> was etcetera, rather than three
letters that mightn't mean etcetera, and they could speak the word or read
out the letters accordingly.

Likewise, some might try to read out MB or MHz as word (I've heard such
strange things, before), but explicitly marked out as abbreviations, and
perhaps also with the unabbreviated version, they're got more chance of
being read as mega byte and mega Hertz. Further to that, explicitly
marking up terms like MB would be even more useful, as some people are
rather bad at using B or b in the wrong place--there's quite a difference
between 1 mega bit and 1 mega byte.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

Jul 24 '05 #40

Nick Kew <ni**@asgard.webthing.com> wrote:

I can spell, and I understand of English grammar and syntax.
"of" ? :)
So (being an arrogant ***), I don't use tools like spellcheckers.

Occasionally I make mistakes - typos, or text that is nonsensical
because I chopped the wrong words or line while editing - that a
spellcheck or similar tool would have helped me avoid.

Regarding web accessibility, a tool like AccessValet helps knowledgeable
users to pick up on that kind of mistake.

I'm not sure what point you are trying to make, is it that accessibility
checkers perform a function similar to checking for spelling errors, or
that AccessValet checks for spelling errors?

If the first then it would help if you provided an accessibility
example, the spelling check analogy is imo flawed.

--
Spartanicus

Jul 24 '05 #41

jake

In message <1q******************************@40tude.net>, Tim
<ti*@mail.localhost.invalid> writes

On Fri, 8 Apr 2005 16:29:27 +0100,
jake <ja**@gododdin.demon.co.uk> posted:
(3) There is nothing to be gained by coding a.m. and p.m. as <acronym>
-- which is wrong anyway, as they're <abbr>.

(4) There's only a need to mark up the first occurrence of <acronym> or
<abbr> on a page.

I'd argue against both points (while agreeing that am and pm are
abbreviations): It's possible for abbreviations to be treated differently
than just text on the page, and I don't just mean hints when you hover the
mouse over them. For instance, it'd take the guesswork out of speech
agents if they knew that <abbr>etc</abbr> was etcetera, rather than three
letters that mightn't mean etcetera, and they could speak the word or read
out the letters accordingly.

Likewise, some might try to read out MB or MHz as word (I've heard such
strange things, before), but explicitly marked out as abbreviations, and
perhaps also with the unabbreviated version, they're got more chance of
being read as mega byte and mega Hertz. Further to that, explicitly
marking up terms like MB would be even more useful, as some people are
rather bad at using B or b in the wrong place--there's quite a difference
between 1 mega bit and 1 mega byte.

Ref. item (3)
How many English speakers do you know who don't know what a.m. and p.m.
means? And what would be the point of marking them up 'ante meridiem'
'post meridiem' (complete with "lang='la")?

Ref. item (4).
If I'm listening to a paper describing the history of modern Russia, do
I really need 'USSR' to be marked up each time as 'Union of the Soviet
Socialist Republics'?
Remember that those few readers that can make anything of <abbr> or
<acronym> do so on an all-or-nothing basis.

As for etc. - well, there's nothing wrong with marking it up as <abbr>
-- but then again, many readers would include common abbreviations in
their dictionaries or provide the option to include it in their
dictionaries.

Marking up an abbreviation/acronym the first time it occurs on a page is
a good thing - but on every occasion? Not for me.

regards.
--
Jake

Jul 24 '05 #42

kchayka

David Ross wrote:

"Jukka K. Korpela" wrote:

The crucial question is: do you wish to help people
with disabilities, or do you wish to get a stamp of approval?

I am trying to be sensitive to persons with disabilities and
handicaps.

If you really do want to aid those visitors, and I believe you do, then
just don't blindly follow either the WAI guidelines or the
recommendations of any automated tool.

WCAG 1.0 is more than 5 years old. A lot has changed since these
guidelines were published. Some recommendations may have been a good
idea at the time, but they never really panned out, or the need for them
has evaporated over time. Yet they persist in the current "standard".
WCAG 2.0 may address them, but that's probably a long way off yet.

Take for example one of my pet peeves:
http://www.w3.org/TR/1999/WAI-WEBCON...tech-tab-order
9.4 Create a logical tab order through links, form controls, and objects.

Which goes on to suggest using the tabindex attribute to acheive this.
Tabindex should *never* be used. Discounting browser support, which is
sketchy, this one can actually create problems rather than alleviate them.

Firstly, the best way to acheive a logical tab order is to structure the
document logically, not simulate it via tabindex. If you do have a
logical structure, tabindex doesn't really buy you anything.

Secondly, if you use a browser that has in-built keyboard navigation and
also happens to support tabindex (e.g. mozilla), setting tabindex can
interfere with the (superior) browser keyboard navigation. BTW,
accesskeys can have the same result.

Thirdly, if you incorporate "skip links" to bypass navigation menus, as
required for Section 508 compliance, tabindex will interfere with it and
defeat the purpose of the skip link.

This is but one example. Weeding out the good from the not-so-good
recommendations takes some research. I wish I could point you to a site
that had some more in-depth coverage of this subject, but I don't know
of any, at least not one that covers more than 1 or 2 specific issues.

Good luck

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.

Jul 24 '05 #43

Nick Kew

kchayka wrote:

If you really do want to aid those visitors, and I believe you do, then
just don't blindly follow either the WAI guidelines or the
recommendations of any automated tool.
Agreed entirely.

To do the Right Thing, replace the word "blindly" with "selectively and
intelligently", and of course don't limit yourself to evaluating
against WAI/WCAG.
WCAG 1.0 is more than 5 years old. A lot has changed since these
guidelines were published.
Indeed. But it still serves a purpose. It's the nearest thing we have
to a consensus view of experts in the industry. The alternative is to
take your own view, or that of a single expert, or some other body such
as a committee that decides your organisation's policy. That will
inevitably be built on less collective experience, and risks falling
into mistakes such as providing for the blind but overlooking other
groups with special or unusual needs.

Now, such an alternative may be valid for you. But what should an
automated checker do? If I ignore the WCAG and implement purely what
*I* think is a good idea, I'm setting *myself* above the WAI consensus.
That's rather a big claim to make for my own expertise. In developing
AccessValet, I paid close attention to the WCAG (and Section508) and
based the warnings on the guidelines, but I have tried also to apply
good judgement by making it clear that different warnings have
different weights, with some of them almost certainly wanting attention,
while others are there for completeness but can probably be ignored.
This is but one example. Weeding out the good from the not-so-good
recommendations takes some research. I wish I could point you to a site
that had some more in-depth coverage of this subject, but I don't know
of any, at least not one that covers more than 1 or 2 specific issues.

Interesting point. It would be a lot of work to create that, but
maybe a collaborative effort - something along the lines of a wiki -
could be introduced at valet or htmlhelp?

--
Nick Kew

Jul 24 '05 #44

Richard Quick

> Take for example one of my pet peeves:

http://www.w3.org/TR/1999/WAI-WEBCON...tech-tab-order
9.4 Create a logical tab order through links, form controls, and objects.

Which goes on to suggest using the tabindex attribute to acheive this.
Tabindex should *never* be used. Discounting browser support, which is
sketchy, this one can actually create problems rather than alleviate them.
Can you expand on this? Other than the problems you've mentioned
below, are there any other orblems it causes?

Obviously I realise that a logical page structure is the best way of
doing things, but if it is a case of improving the accessibility of a
legacy system, rather than cading a site from scratch, is there any
reason _not_ to use a tab index (or accesskeys), if it's used
sensibly?

Firstly, the best way to acheive a logical tab order is to structure the
document logically, not simulate it via tabindex. If you do have a
logical structure, tabindex doesn't really buy you anything.

Secondly, if you use a browser that has in-built keyboard navigation and
also happens to support tabindex (e.g. mozilla), setting tabindex can
interfere with the (superior) browser keyboard navigation. BTW,
accesskeys can have the same result.

Thirdly, if you incorporate "skip links" to bypass navigation menus, as
required for Section 508 compliance, tabindex will interfere with it and
defeat the purpose of the skip link.

Jul 24 '05 #45