By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,246 Members | 1,304 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,246 IT Pros & Developers. It's quick & easy.

Any advice?

P: n/a
I've been writing http://www.villagefabrics.co.uk since the end of December.
It's finally at a stage where I would really appreciate some feedback on the
design/code/accessibility and anything else that looks wrong.

Many thanks,

Karen McAtamney

--
we*******@villagefabrics.co.uk
Jul 20 '05 #1
Share this Question
Share on Google+
56 Replies


P: n/a
"Karen McAtamney" <ka************@members.v21.co.uk> wrote in message
news:40********@news.greennet.net...
I've been writing http://www.villagefabrics.co.uk since the end of December. It's finally at a stage where I would really appreciate some feedback on the design/code/accessibility and anything else that looks wrong.


I'll try to offer constructive critisism. :)

1. The navigation bar looks strange... not really lined up with anything in
particular. The wider I make my display, the further down the page the
navigation moves. I would change that.
2. The links within the navigation box don't contrast with the background
color... blue on blue, and orange on blue for visited links. Also, they
don't line up very well. Looks like they are centered within some box that
is right aligned within the navigation box.
3. What is this "Skip Navigation Bar" thing??? Doesn't provide any useful
functionality... I would remove it.

I think your navigation section needs the most work. I would focus on that.
Regards,
Peter Foti
Jul 20 '05 #2

P: n/a
"Karen McAtamney" <ka************@members.v21.co.uk> wrote in
news:40********@news.greennet.net:
I've been writing http://www.villagefabrics.co.uk since the end of
December. It's finally at a stage where I would really appreciate some
feedback on the design/code/accessibility and anything else that looks
wrong.


The main problems I see involve the navigation bar:

1) Dark blue on light blue is very hard to read.
2) Links to the current page shouldn't be active (following one doesn't
appear to change anything, but does insert an extra entry into the browser
history so the next activation of the back button doesn't appear to do
anything either).
3) I'd prefer left-aligned, rather than centered, text in the nav bar.
4) I'd prefer no underlining of links in the nav bar (links in the main
text, though, should continue to be underlined).
5) In MSIE6, the vertical spacing in the nav bar is excessive.

Other than that, the design scales well.

Code considerations:

1) The use of <map> in the navbar is nonsensical; it's intended to enclose
client-side imagemaps.
2) You have some redundant alt attributes like "Village Fabrics Logo" and
"Google"; alt attributes should be set to "" in cases where there's
already an adjacent text equivalent of the image's content so as not to
double up the content when images are off or not yet loaded.
3) For maintainability, it's better to choose class names that represent
the intended function of elements rather than their implementation; for
example <div class="nav"> makes more sense for a navbar than <div
class="ul">.
Jul 20 '05 #3

P: n/a

"Peter Foti" <pe***@Idontwantnostinkingemailfromyou.com> wrote in message
news:10*************@corp.supernews.com...
"Karen McAtamney" <ka************@members.v21.co.uk> wrote in message
news:40********@news.greennet.net...
I've been writing http://www.villagefabrics.co.uk since the end of December.


[snip]
3. What is this "Skip Navigation Bar" thing??? Doesn't provide any useful
functionality... I would remove it.


On the contrary, it's an accessibility feature for people using aural UAs,
so they can skip the repetitive navigation and jump to the content.
Typically it's done using one of a couple of techniques that keep visual UA
users from being aware of it.

[snip]

Jul 20 '05 #4

P: n/a
in post: <news:bv************@ID-114100.news.uni-berlin.de>
"Harlan Messinger" <h.*********@comcast.net> said:
3. What is this "Skip Navigation Bar" thing??? Doesn't provide any useful
functionality... I would remove it.
On the contrary, it's an accessibility feature for people using aural UAs,
so they can skip the repetitive navigation and jump to the content.


some VI people like them, some don't. if the VI person wants/needs that
kind of functionality then they should use a UA that allows sections to
be skipped. of more practical benefit would be to move the menu markup
to the bottom of the html. also dump the accesskeys.
--
brucie - i usenet nude
Jul 20 '05 #5

P: n/a
"Harlan Messinger" <h.*********@comcast.net> wrote in message
news:bv************@ID-114100.news.uni-berlin.de...

"Peter Foti" <pe***@Idontwantnostinkingemailfromyou.com> wrote in message
news:10*************@corp.supernews.com...
"Karen McAtamney" <ka************@members.v21.co.uk> wrote in message
news:40********@news.greennet.net...
I've been writing http://www.villagefabrics.co.uk since the end of December.


[snip]
3. What is this "Skip Navigation Bar" thing??? Doesn't provide any useful functionality... I would remove it.


On the contrary, it's an accessibility feature for people using aural UAs,
so they can skip the repetitive navigation and jump to the content.
Typically it's done using one of a couple of techniques that keep visual

UA users from being aware of it.

[snip]


In this case, it seems to be lacking one of those techniques. Even so, it
seems like sort of a hack. Why not simply put the navigation after the
content and use CSS to reposition it for visual UAs?

Peter

Jul 20 '05 #6

P: n/a
"Eric Bohlman" <eb******@earthlink.net> wrote in message
news:Xn*******************************@130.133.1.4 ...
"Karen McAtamney" <ka************@members.v21.co.uk> wrote in
news:40********@news.greennet.net:
2) You have some redundant alt attributes like "Village Fabrics Logo" and
"Google"; alt attributes should be set to "" in cases where there's
already an adjacent text equivalent of the image's content so as not to
double up the content when images are off or not yet loaded.


Note, in the case of "Google", there is no adjacent text equivalent of the
image's content, so for that particular case she was correct to include the
alt attribute.

Regards,
Peter Foti
Jul 20 '05 #7

P: n/a
in post: <news:40********@news.greennet.net>
"Karen McAtamney" <ka************@members.v21.co.uk> said:
I've been writing http://www.villagefabrics.co.uk since the end of December.
It's finally at a stage where I would really appreciate some feedback on the
design/code/accessibility and anything else that looks wrong.


its very rough and you really need a new logo but perhaps this will give
you some ideas: http://moreshit.bruciesusenetshit.info/karen/
--
brucie - i usenet nude
Jul 20 '05 #8

P: n/a
> I'll try to offer constructive critisism. :)

Thank you - always appreciated;-)
1. The navigation bar looks strange... not really lined up with anything in particular. The wider I make my display, the further down the page the
navigation moves. I would change that.
Hmm - it's set so that it's 15% of the way down the page - to prevent it
starting parallel to the <h1> on the page, but I don't see why that would
cause it to change size when you make your screen wider.
2. The links within the navigation box don't contrast with the background
color... blue on blue, and orange on blue for visited links. Also, they
don't line up very well. Looks like they are centered within some box that is right aligned within the navigation box.


This is because the links are all within a <ul> tag, which places them off
centre. From an accessibility point of view, they need to be grouped
together using such a tag, and I've not yet worked out how to fix the
formatting for that.

Will work on colour contrast.

Many thanks,

Karen
Jul 20 '05 #9

P: n/a
> some VI people like them, some don't. if the VI person wants/needs that
kind of functionality then they should use a UA that allows sections to
be skipped. of more practical benefit would be to move the menu markup
to the bottom of the html. also dump the accesskeys.


It won't, however, do anyone any harm, and might well prove useful to some
people (more than just those using screen readers - many people using Lynx
find them useful. I am intending to insert a piece of CSS to hide it from
graphical browsers.

Moving the menu markup, I will consider.

What's the problem with accesskeys? - http://www.w3.org's accessibility
guidelines specifically recommends using them.

Many thanks,

Karen
Jul 20 '05 #10

P: n/a
> The main problems I see involve the navigation bar:

1) Dark blue on light blue is very hard to read.
2) Links to the current page shouldn't be active (following one doesn't
appear to change anything, but does insert an extra entry into the browser
history so the next activation of the back button doesn't appear to do
anything either).
*nods* - I'm working on a Server Side Include that will enable me to remove
all of that code from the individual webpages and display a bold non-link
for the current page.
3) I'd prefer left-aligned, rather than centered, text in the nav bar.
They look very odd when left-aligned, due to the way the <ul> tag causes
them to be off-centre.
4) I'd prefer no underlining of links in the nav bar (links in the main
text, though, should continue to be underlined).
Most users expect links to be underlined though - removing the underlining
could be confusing - particularly since my customers are unlikely to be the
most web savvy.
5) In MSIE6, the vertical spacing in the nav bar is excessive.
I have absolutely no idea how to alter that.
Other than that, the design scales well.
Thank you,
Code considerations:

1) The use of <map> in the navbar is nonsensical; it's intended to enclose
client-side imagemaps.
Also recommended by the W3's accessibility guidelines as a way to group
navigation features to aid users with screen readers.
2) You have some redundant alt attributes like "Village Fabrics Logo" and
"Google"; alt attributes should be set to "" in cases where there's
already an adjacent text equivalent of the image's content so as not to
double up the content when images are off or not yet loaded.
*nods* - I'd read that the first time something like a logo is used it
should have a substantive alt tag, and then when repeated the alt should be
"".
3) For maintainability, it's better to choose class names that represent
the intended function of elements rather than their implementation; for
example <div class="nav"> makes more sense for a navbar than <div
class="ul">.


Will be fixed when I implement the SSI.

Many thanks,

Karen
Jul 20 '05 #11

P: n/a
> its very rough and you really need a new logo but perhaps this will give
you some ideas: http://moreshit.bruciesusenetshit.info/karen/


It does indeed, thank you very much.

Karen
Jul 20 '05 #12

P: n/a
in post: <news:40******@news.greennet.net>
"Karen McAtamney" <ka************@members.v21.co.uk> said:
some VI people like them, some don't. if the VI person wants/needs that
kind of functionality then they should use a UA that allows sections to
be skipped. of more practical benefit would be to move the menu markup
to the bottom of the html. also dump the accesskeys.
It won't, however, do anyone any harm, and might well prove useful to some
people (more than just those using screen readers - many people using Lynx
find them useful.
then the many people using lynx should ask the developer to add support
for skipping content or use another UA with it already built in.
I am intending to insert a piece of CSS to hide it from graphical
browsers.
that would also result in it being hidden from a lot of screen readers.
makes the whole thing a bit pointless.
What's the problem with accesskeys? accessibility guidelines
specifically recommends using them.


some of the /guidelines/ hinder accessibility, not improve it

--
brucie - i usenet nude
Jul 20 '05 #13

P: n/a
"Karen McAtamney" <ka************@members.v21.co.uk> wrote in
news:40******@news.greennet.net:
I'll try to offer constructive critisism. :)
Thank you - always appreciated;-)
1. The navigation bar looks strange... not really lined up with
anything

in
particular. The wider I make my display, the further down the page
the navigation moves. I would change that.


Hmm - it's set so that it's 15% of the way down the page - to
prevent it starting parallel to the <h1> on the page, but I don't see
why that would cause it to change size when you make your screen
wider.


Because when your main content correctly reflows according to the viewport
width, as yours does, changing the viewport width changes the height of the
content.
This is because the links are all within a <ul> tag, which places them
off centre. From an accessibility point of view, they need to be
grouped together using such a tag, and I've not yet worked out how to
fix the formatting for that.


See <http://css.maxdesign.com.au/listutorial/index.htm>, among other
places, for ideas. You might look at what I did for
<http://www.wayneengineering.com/products.html>; both the vertical and
horizontal navbars there are done with <ul>.
Jul 20 '05 #14

P: n/a
brucie <sh**@bruciesusenetshit.info> wrote:
that would also result in it being hidden from a lot of screen
readers. makes the whole thing a bit pointless.
What if media="screen"?
some of the /guidelines/ hinder accessibility, not improve it


Could you explain this?
--
Michael Wilcox
mjwilco at yahoo dot com
Essential Tools for the Web Developer - http://mikewilcox.t35.com
Jul 20 '05 #15

P: n/a
in post: <news:Xo*****************@newsread1.news.atl.earth link.net>
"Michael Wilcox" <mj*****************@yahoo.com> said:
that would also result in it being hidden from a lot of screen
readers. makes the whole thing a bit pointless.
What if media="screen"?
nope.
some of the /guidelines/ hinder accessibility, not improve it

Could you explain this?


no, the thread would just turn into a jihad. google previous posts.

--
brucie - i usenet nude
Jul 20 '05 #16

P: n/a
On Fri, 30 Jan 2004 21:02:12 -0000, "Karen McAtamney"
<ka************@members.v21.co.uk> wrote:
I've been writing http://www.villagefabrics.co.uk since the end of
December. It's finally at a stage where I would really appreciate
some feedback on the design/code/accessibility and anything else
that looks wrong.


I just wanted to wave and say "hi" :)

Cheers,
Philip
--
Philip Newton <no***********@gmx.li>
That really is my address; no need to remove anything to reply.
If you're not part of the solution, you're part of the precipitate.
Jul 20 '05 #17

P: n/a
On Sat, 31 Jan 2004 11:09:38 +1000, brucie <sh**@bruciesusenetshit.info>
wrote:
in post: <news:40******@news.greennet.net>
"Karen McAtamney" <ka************@members.v21.co.uk> said:
I am intending to insert a piece of CSS to hide it from graphical
browsers.


that would also result in it being hidden from a lot of screen readers.
makes the whole thing a bit pointless.


If visibility: hidden; is used, yes. There are other positioning methods
that a screen reader will ignore.
Jul 20 '05 #18

P: n/a
in post: <news:op**************@news.rcn.com>
Neal <ne*****@spamrcn.com> said:
that would also result in it being hidden from a lot of screen readers.
makes the whole thing a bit pointless.
If visibility: hidden; is used, yes.
and display:none
There are other positioning methods that a screen reader will ignore.


it depends on the screen reader.

--
brucie - i usenet nude
Jul 20 '05 #19

P: n/a
> I just wanted to wave and say "hi" :)

Oh hi Philip - had to do a double take there - Usenet not being known for
its friendly welcome:-)

Karen
Jul 20 '05 #20

P: n/a
In message <40********@news.greennet.net>, Karen McAtamney
<ka************@members.v21.co.uk> writes
I've been writing http://www.villagefabrics.co.uk since the end of December.
It's finally at a stage where I would really appreciate some feedback on the
design/code/accessibility and anything else that looks wrong.

Many thanks,

Karen McAtamney

Sounds like quite a nice site: easy to navigate and listen to.

A few comments:

(a) The provision of a 'Skip Navigation Bar' link as the first entry in
the navigation block is a good thing. If you want in hidden from
graphical browsers, just replace the textual link with a link based on a
1-pixel image with its alternative text set to 'Skip Navigation'.

(b) Drop the <map></map> surrounding the navigation block as all I hear
is 'Start of Navigation with zero items' and the 'End of Map' ......
quite meaningless.

(c) You could set the alternative text on the logo to ALT="" as it's
just repeating the text that's in the adjacent header.

(d) Some of your 'skip navigation links' don't work e.g. books,
magazines.

(e) Deactivate the link on each page that points to itself.

(f) replace some of the abbreviations with text:
[incl.] --> [including]
["] --> [inches]
[x] --> [by]

(g) Some of your lists are marked up as (example):
Country Threads<br>
Homespun<br>
Australian Patchworks and Quilts<br>
........

Screen readers will tend to run the words together; try putting in some
punctuation at the end of each line (e.g. a comma ).

Suggestion:
Read the pages aloud and only pause when you see punctuation marks or a
header. this will give you a clue as to where some punctuation might be
useful.

(h) The use of headers on 'snippets' doesn't seem to quite right. Are
you using them to control the font size?

(i) Last and least (for time being). Run your text through a
grammar/spell-checker to pick up all the errors and types.
e.g.
........ together(and who ........ {needs a space}
.......whichmay ...... {needs a space}
clanedar {should be 'calendar'}
etc.

Nice site.

Regards
--
Jake
Jul 20 '05 #21

P: n/a
brucie <sh**@bruciesusenetshit.info> wrote:
in post: <news:bv************@ID-114100.news.uni-berlin.de>
"Harlan Messinger" <h.*********@comcast.net> said:
3. What is this "Skip Navigation Bar" thing??? Doesn't provide any useful
functionality... I would remove it.
On the contrary, it's an accessibility feature for people using aural UAs,
so they can skip the repetitive navigation and jump to the content.


some VI people like them, some don't. if the VI person wants/needs that
kind of functionality then they should use a UA that allows sections to
be skipped. of more practical benefit would be to move the menu markup
to the bottom of the html.


I am on fully board for following, as much as possible, practices that
make web pages accessible to those with various sensory or motor
impairments. I accept the extent to which that influences how I put
the visual appearance together. But now you're not talking about
accommodation, you're talking about catering to individual
preferences. Weighing "I can't use this page" against my, or my
client's, design ideas, "I can't use this page" is compelling.
Weighing "But I don't *like* having to click a link to get to the
content!" against other design considerations, I come up with, "Why do
your preferences and convenience outweigh everybody else's?"

Besides, your recommendation is in direct conflict with *usability*
principles. On a visual presentation, usability considerations demand
that controls (navigation, forms, etc) be prominent.
also dump the accesskeys


I agree. Access keys are only good for interfaces that are stable and
that one is likely to use many times and become familiar with, like a
data entry form on an application one uses regularly in one's work. If
the a person's use of an interface ends before the person has had a
chance to learn the access keys, then they haven't served any purpose.

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.
Jul 20 '05 #22

P: n/a
brucie <sh**@bruciesusenetshit.info> wrote:
in post: <news:op**************@news.rcn.com>
Neal <ne*****@spamrcn.com> said:
that would also result in it being hidden from a lot of screen readers.
makes the whole thing a bit pointless.

If visibility: hidden; is used, yes.


and display:none
There are other positioning methods that a screen reader will ignore.


it depends on the screen reader.


z-index: -9;

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.
Jul 20 '05 #23

P: n/a
"Peter Foti" <pe***@Idontwantnostinkingemailfromyou.com> wrote:
"Harlan Messinger" <h.*********@comcast.net> wrote in message
news:bv************@ID-114100.news.uni-berlin.de...

"Peter Foti" <pe***@Idontwantnostinkingemailfromyou.com> wrote in message
news:10*************@corp.supernews.com...
> "Karen McAtamney" <ka************@members.v21.co.uk> wrote in message
> news:40********@news.greennet.net...
> > I've been writing http://www.villagefabrics.co.uk since the end of
> December.


[snip]
> 3. What is this "Skip Navigation Bar" thing??? Doesn't provide anyuseful > functionality... I would remove it.


On the contrary, it's an accessibility feature for people using aural UAs,
so they can skip the repetitive navigation and jump to the content.
Typically it's done using one of a couple of techniques that keep visual

UA
users from being aware of it.

[snip]


In this case, it seems to be lacking one of those techniques. Even so, it
seems like sort of a hack. Why not simply put the navigation after the
content and use CSS to reposition it for visual UAs?


It's no more a "hack" then any other accommodation. See my response to
Brucie for more thoughts.

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.
Jul 20 '05 #24

P: n/a
On Sat, 31 Jan 2004, jake wrote:
(b) Drop the <map></map> surrounding the navigation block as all I hear
is 'Start of Navigation with zero items' and the 'End of Map' ......
quite meaningless.


Did you mention which browser you are using? When I did a trial of
IBM HPR, I had to fault it on its useless implementation of
client-side maps. It sounds to me as if, in this case, Karen is doing
something with <map> that's slightly unusual but perfectly valid
according to HTML specifications, and the fault lies in the browser
for failing to implement it correctly.

OK, for sure it would be nice to avoid provoking such a problem in the
first place - I'm only trying to put the blame in the proper place.

all the best
Jul 20 '05 #25

P: n/a
On Sat, 31 Jan 2004 00:47:15 -0000, "Karen McAtamney"
<ka************@members.v21.co.uk> wrote:
2) You have some redundant alt attributes like "Village Fabrics Logo" and
"Google"; alt attributes should be set to "" in cases where there's
already an adjacent text equivalent of the image's content so as not to
double up the content when images are off or not yet loaded.


*nods* - I'd read that the first time something like a logo is used it
should have a substantive alt tag, and then when repeated the alt should be
"".


The simplest rule is to view the page with images turned off (or in a
text browser) and see how much sense it makes. You probably need to do
that anyway to determine whether the ALT texts need trailing spaces,
punctuation etc.

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/
Jul 20 '05 #26

P: n/a
In message <uk********************************@4ax.com>, Harlan
Messinger <hm*******************@comcast.net> writes
brucie <sh**@bruciesusenetshit.info> wrote:
in post: <news:bv************@ID-114100.news.uni-berlin.de>
"Harlan Messinger" <h.*********@comcast.net> said:
3. What is this "Skip Navigation Bar" thing??? Doesn't provide any useful
functionality... I would remove it.

On the contrary, it's an accessibility feature for people using aural UAs,
so they can skip the repetitive navigation and jump to the content.


some VI people like them, some don't. if the VI person wants/needs that
kind of functionality then they should use a UA that allows sections to
be skipped. of more practical benefit would be to move the menu markup
to the bottom of the html.


I am on fully board for following, as much as possible, practices that
make web pages accessible to those with various sensory or motor
impairments. I accept the extent to which that influences how I put
the visual appearance together. But now you're not talking about
accommodation, you're talking about catering to individual
preferences. Weighing "I can't use this page" against my, or my
client's, design ideas, "I can't use this page" is compelling.
Weighing "But I don't *like* having to click a link to get to the
content!" against other design considerations, I come up with, "Why do
your preferences and convenience outweigh everybody else's?"

Besides, your recommendation is in direct conflict with *usability*
principles. On a visual presentation, usability considerations demand
that controls (navigation, forms, etc) be prominent.

[snip]

Just a comment or two.

Most readers give the user the ability to navigate a site, from
block-level all the way down to character-level, backwards-and-forwards.

On a well-structured and (guaranteed) consistent layout between pages,
using 'headers' for navigation is just fine.

So, for example, when you visit a page you know that you can trust, you
can:
(a) pause the speaking of the navigation bar
(b) go into 'header-reading' mode
(c) skip to the first header and start reading, confident that you have
gone to the start of the content.

However, if the site isn't well marked-up and consistent than you can't
do as above and a 'skip navigation' link is valuable.

This site is consistent. But the *first-time* visitor isn't going to
know that.

regards.

One suggestion is to rearrange the text and use CSS to position it so
that the content is read first, and the navigation links last.

Not a bad approach it. But then again, if you want to get quickly to the
navigation bar, you are going to need a 'Skip Content' link at the start
of the text ;-)
--
Jake
Jul 20 '05 #27

P: n/a
Eric Bohlman wrote:
"Karen McAtamney" <ka************@members.v21.co.uk> wrote in
news:40********@news.greennet.net:
http://www.villagefabrics.co.uk


The main problems I see involve the navigation bar:

1) Dark blue on light blue is very hard to read.


No, it's light blue on medium blue. :)

The real problem is that she hasn't specifically set a:link colors, just
:visited. You are seeing your browser default link color against her
specified background color. Readability is therefore indeterminate.

--
To email a reply, remove (dash)un(dash). Mail sent to the un
address is considered spam and automatically deleted.
Jul 20 '05 #28

P: n/a
In message <Pi******************************@ppepc56.ph.gla.a c.uk>, Alan
J. Flavell <fl*****@ph.gla.ac.uk> writes
On Sat, 31 Jan 2004, jake wrote:
(b) Drop the <map></map> surrounding the navigation block as all I hear
is 'Start of Navigation with zero items' and the 'End of Map' ......
quite meaningless.
Did you mention which browser you are using? When I did a trial of
IBM HPR, I had to fault it on its useless implementation of
client-side maps.


HPR/IE6.

That's interesting. Which version did you test with? and what was it
particularly about its handling of client-side maps that you didn't
like?

I can't say that I've seen any problems with correctly marked up
client-side images/maps, so I'd be interested in hearing what you think.
It sounds to me as if, in this case, Karen is doing
something with <map> that's slightly unusual but perfectly valid
according to HTML specifications, and the fault lies in the browser
for failing to implement it correctly.

OK, for sure it would be nice to avoid provoking such a problem in the
first place - I'm only trying to put the blame in the proper place.

all the best


I'm sure you're right.

I tend to take the avoid-provoking-such-a-problem-in-the-first-place
approach ;-)

regards.
--
Jake
Jul 20 '05 #29

P: n/a
In message <70********************************@4ax.com>, Stephen Poley
<sb******************@xs4all.nl> writes
On Sat, 31 Jan 2004 00:47:15 -0000, "Karen McAtamney"
<ka************@members.v21.co.uk> wrote:
2) You have some redundant alt attributes like "Village Fabrics Logo" and
"Google"; alt attributes should be set to "" in cases where there's
already an adjacent text equivalent of the image's content so as not to
double up the content when images are off or not yet loaded.


*nods* - I'd read that the first time something like a logo is used it
should have a substantive alt tag, and then when repeated the alt should be
"".


The simplest rule is to view the page with images turned off (or in a
text browser) and see how much sense it makes. You probably need to do
that anyway to determine whether the ALT texts need trailing spaces,
punctuation etc.

Seems like a good idea.

regards.
--
Jake
Jul 20 '05 #30

P: n/a
On Sat, 31 Jan 2004, jake wrote:
In message <Pi******************************@ppepc56.ph.gla.a c.uk>, Alan
J. Flavell <fl*****@ph.gla.ac.uk> writes

Did you mention which browser you are using? When I did a trial of
IBM HPR, I had to fault it on its useless implementation of
client-side maps.
HPR/IE6.

That's interesting. Which version did you test with?


I've just checked back: it would have been HPR version 3.02, late in
2002. I guess the underlying browser would have been IE5.5 - or just
possibly IE5, I'm no longer certain which, sorry.
and what was it particularly about its handling of client-side maps
that you didn't like?
For the customary imagemap with areas and alt attributes, I was quite
astonished that it read out (as I recall) "Start of imagemap, end of
imagemap" with nothing in between. It did nothing at all with the
areas and alt attributes. I tried it on a number of examples to see
if there was some specific feature that was upsetting it, but they all
seemed to behave the same. It simply frustrated the user by telling
them of the presence of an imagemap, but did nothing to make it
usable.

OK, so I'm very pleased to hear that it's got that sorted out since.
I can't say that I've seen any problems with correctly marked up
client-side images/maps, so I'd be interested in hearing what you think.


Well, either my experiences are out of date, or there was something
wrong with the way my HPR was installed for the trial period. But if
it was the latter, then in every other respect the HPR seemed to be
behaving in a plausible fashion.

I'm very relieved to learn from you that its behaviour is (now)
sensible, at least with conventional area-based client-side maps.

all the best
Jul 20 '05 #31

P: n/a
Michael Wilcox wrote:
brucie <sh**@bruciesusenetshit.info> wrote:
that would also result in it being hidden from a lot of screen
readers. makes the whole thing a bit pointless.

What if media="screen"?


screen reader, not aural browser.

--
Brian (follow directions in my address to email me)
http://www.tsmchughs.com/

Jul 20 '05 #32

P: n/a
Karen McAtamney wrote:

What's the problem with accesskeys?
An accesskey that you define may already be a shortcut key in the
user's browser. In such a case, pressing that accesskey will have a
different result than keyboard users are accustomed to.
- http://www.w3.org's accessibility guidelines specifically
recommends using them.


Just because the w3c says it, doesn't make it true.

--
Brian (follow directions in my address to email me)
http://www.tsmchughs.com/

Jul 20 '05 #33

P: n/a
In message <Pi******************************@ppepc56.ph.gla.a c.uk>, Alan
J. Flavell <fl*****@ph.gla.ac.uk> writes
On Sat, 31 Jan 2004, jake wrote:
In message <Pi******************************@ppepc56.ph.gla.a c.uk>, Alan
J. Flavell <fl*****@ph.gla.ac.uk> writes
>
>Did you mention which browser you are using? When I did a trial of
>IBM HPR, I had to fault it on its useless implementation of
>client-side maps.


HPR/IE6.

That's interesting. Which version did you test with?


I've just checked back: it would have been HPR version 3.02, late in
2002. I guess the underlying browser would have been IE5.5 - or just
possibly IE5, I'm no longer certain which, sorry.
and what was it particularly about its handling of client-side maps
that you didn't like?


For the customary imagemap with areas and alt attributes, I was quite
astonished that it read out (as I recall) "Start of imagemap, end of
imagemap" with nothing in between. It did nothing at all with the
areas and alt attributes. I tried it on a number of examples to see
if there was some specific feature that was upsetting it, but they all
seemed to behave the same. It simply frustrated the user by telling
them of the presence of an imagemap, but did nothing to make it
usable.

OK, so I'm very pleased to hear that it's got that sorted out since.
I can't say that I've seen any problems with correctly marked up
client-side images/maps, so I'd be interested in hearing what you think.


Well, either my experiences are out of date, or there was something
wrong with the way my HPR was installed for the trial period. But if
it was the latter, then in every other respect the HPR seemed to be
behaving in a plausible fashion.

I'm very relieved to learn from you that its behaviour is (now)
sensible, at least with conventional area-based client-side maps.

all the best


OK. Well, I've got the 3.021 patches installed, running on IE6.

Typically, if I come across a (hypothetical) 3-area map I hear something
along the lines of:

[menu items]
[Start of map with 3 items]
[End of Map]
Then, when I access the map -- stopping HPR speaking and then using the
left arrow -- I hear (in a 'links' voice):

[Software available]
[Current patches]
[Fixes Available]

where 'Software available', 'Current patches', and 'Fixes available' is
the alternative text on the <area> tags, and 'menu items' is the <title>
text on the <img>.

One common problem with a lot of pages using image maps is the failure
to include proper <title> and <alt> entries. HPR does it's best to
construct a link to speak, based on it's position in the file hierarchy,
but hearing something like [/upperlayer/diags/best_23_5.html] isn't too
helpful.

regards.

--
Jake
Jul 20 '05 #34

P: n/a
In article <xlSSb.198861$na.330904@attbi_s04>,
Brian <us*****@julietremblay.com.invalid-remove-this-part> writes:
Karen McAtamney wrote:

What's the problem with accesskeys?


An accesskey that you define may already be a shortcut key in the
user's browser. In such a case, pressing that accesskey will have a
different result than keyboard users are accustomed to.


Yep. A good idea botched by broken browser implementations.
- http://www.w3.org's accessibility guidelines specifically
recommends using them.


Just because the w3c says it, doesn't make it true.


At the time the guidelines were published, there was too little
browser support to worry about. Now browser support has arrived,
but is so broken as to be worse than useless, at least in a certain
so-called browserthat is too widely used to ignore.

If you check the mailinglists, the same working group that published
those guidelines now has a consensus against them.

Tools may suggest you use accesskeys, but that's because tool
developers recognise that the guidelines represent a broad consensus
that is more useful to our users than just what we may happen to
believe. And indeed, it's legitimate for a tool to suggest you
consider using accesskey or tabindex for navigation: there are
cases when they are indeed appropriate. But my advice to
AccessValet users is that in most cases, you'll want to mark
that particular warning "Not applicable".

--
Nick Kew
Jul 20 '05 #35

P: n/a
in post: <news:5q********************************@4ax.com >
Harlan Messinger <hm*******************@comcast.net> said:
that would also result in it being hidden from a lot of screen readers.
makes the whole thing a bit pointless. If visibility: hidden; is used, yes.
and display:none There are other positioning methods that a screen reader will ignore.
it depends on the screen reader.

z-index: -9;


that may not work either, or positioning elements off the canvas area.
as i said, it depends on the screen reader

--
brucie - i usenet nude
Jul 20 '05 #36

P: n/a
On Sat, 31 Jan 2004, jake wrote:
One common problem with a lot of pages using image maps is the failure
to include proper <title> and <alt> entries.


How true, how true. The imagemap tutorial page that I'm just going to
cite isn't exactly the latest - I wrote it some years back - but
you'll find that I repeatedly emphasise the point about providing
meaningful ALT texts, and I provide both ALT and TITLE attributes on
the worked example:

http://ppewww.ph.gla.ac.uk/~flavell/www/imgmaptut.html

Which was why I was especially disappointed when I found HPR doing
what I previously described to you.

But if it's all working in their current version, or if my experience
was some kind of anomaly, then I'm happy.
Jul 20 '05 #37

P: n/a
brucie <sh**@bruciesusenetshit.info> wrote:
in post: <news:5q********************************@4ax.com >
Harlan Messinger <hm*******************@comcast.net> said:
> that would also result in it being hidden from a lot of screen readers.
> makes the whole thing a bit pointless. If visibility: hidden; is used, yes.and display:none There are other positioning methods that a screen reader will ignore.it depends on the screen reader.

z-index: -9;


that may not work either, or positioning elements off the canvas area.
as i said, it depends on the screen reader


Too clever for their own good, eh?

Actually, I assume not everyone here is aware of it, but in the US the
one of the 16 provisions spelling out accessibility requirements for
government-sponsored web sites says, "A method shall be provided that
permits users to skip repetitive navigation links." So some of us
actually need to do this.

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.
Jul 20 '05 #38

P: n/a
in post: <news:bK**************@gododdin.demon.co.uk>
jake <ja**@gododdin.demon.co.uk> said:
just replace the textual link with a link based on a
1-pixel image with its alternative text set to 'Skip Navigation'.


firewalls/proxies/ad filters/etc may think its a webbug and remove it.
for example 6px x 1px is as small as you can go with zonealarm.
--
brucie - i usenet nude
Jul 20 '05 #39

P: n/a
in post: <news:si********************************@4ax.com >
Harlan Messinger <hm*******************@comcast.net> said:
that may not work either, or positioning elements off the canvas area.
as i said, it depends on the screen reader
Too clever for their own good, eh?
its bloody annoying!
Actually, I assume not everyone here is aware of it, but in the US the
one of the 16 provisions spelling out accessibility requirements for
government-sponsored web sites says, "A method shall be provided that
permits users to skip repetitive navigation links." So some of us
actually need to do this.


IMO skipping bits is a function best left to the UA or there will be no
end of extras authors would need to add to their sites. what about links
skipping back to the nav? e.g. if a blind person skipped the nav how do
they know where to go to get back to it? not so bad if the nav is at the
start of the page but what about nav in the center of a page.

--
brucie - i usenet nude
Jul 20 '05 #40

P: n/a
Nick Kew wrote:
In article <xlSSb.198861$na.330904@attbi_s04> Brian writes:
An accesskey that you define may already be a shortcut key in the
user's browser. In such a case, pressing that accesskey will
have a different result than keyboard users are accustomed to.


Yep. A good idea botched by broken browser implementations.


Out of curiousity, how should (indeed, could!) they have implemented
accesskey without interfering with browser keyboard shortcuts?

--
Brian (follow directions in my address to email me)
http://www.tsmchughs.com/

Jul 20 '05 #41

P: n/a
In article <4sWSb.200212$na.331329@attbi_s04>,
Brian <us*****@julietremblay.com.invalid-remove-this-part> writes:
Out of curiousity, how should (indeed, could!) they have implemented
accesskey without interfering with browser keyboard shortcuts?


By using some combo of accesskey with others (eg shift, ctrl, alt)
that isn't part of any builtin controls for the browser and platform.

--
Nick Kew
Jul 20 '05 #42

P: n/a
On Sat, 31 Jan 2004 23:15:39 +0000, Nick Kew <ni**@hugin.webthing.com>
wrote:
In article <4sWSb.200212$na.331329@attbi_s04>,
Brian <us*****@julietremblay.com.invalid-remove-this-part> writes:
Out of curiousity, how should (indeed, could!) they have implemented
accesskey without interfering with browser keyboard shortcuts?


By using some combo of accesskey with others (eg shift, ctrl, alt)
that isn't part of any builtin controls for the browser and platform.


As it's the browser manufacturer who decides this, and who is likely to
change its mind, why not have browsers offer the ability to custimize how
accesskeys are used? I'm envisioning check boxes:

Access Keys
[]Shift
[]Ctrl
[]Alt

Like that. The user can choose to use zero or more of these keys to let
access keys function.
Jul 20 '05 #43

P: n/a
In message <rh************@webthing.com>, Nick Kew
<ni**@hugin.webthing.com> writes
In article <4sWSb.200212$na.331329@attbi_s04>,
Brian <us*****@julietremblay.com.invalid-remove-this-part> writes:
Out of curiousity, how should (indeed, could!) they have implemented
accesskey without interfering with browser keyboard shortcuts?


By using some combo of accesskey with others (eg shift, ctrl, alt)
that isn't part of any builtin controls for the browser and platform.

Screen readers already use shift, alt and ctl combinations for their
commands.

Fortunately, most of them just ignore accesskeys completely ;-)

regards.

--
Jake
Jul 20 '05 #44

P: n/a
In message <bv************@ID-117621.news.uni-berlin.de>, brucie
<sh**@bruciesusenetshit.info> writes
in post: <news:bK**************@gododdin.demon.co.uk>
jake <ja**@gododdin.demon.co.uk> said:
just replace the textual link with a link based on a
1-pixel image with its alternative text set to 'Skip Navigation'.


firewalls/proxies/ad filters/etc may think its a webbug and remove it.
for example 6px x 1px is as small as you can go with zonealarm.

Interesting ....... never come across that one before.

In that case, just make it a 6x1px transparent gif ;-)
--
Jake
Jul 20 '05 #45

P: n/a
In article <wU**************@gododdin.demon.co.uk>,
jake <ja**@gododdin.demon.co.uk> writes:
Out of curiousity, how should (indeed, could!) they have implemented
accesskey without interfering with browser keyboard shortcuts?


By using some combo of accesskey with others (eg shift, ctrl, alt)
that isn't part of any builtin controls for the browser and platform.

Screen readers already use shift, alt and ctl combinations for their
commands.


What part of "eg" don't you understand?

--
Nick Kew
Jul 20 '05 #46

P: n/a
In message <ld************@webthing.com>, Nick Kew
<ni**@hugin.webthing.com> writes
In article <wU**************@gododdin.demon.co.uk>,
jake <ja**@gododdin.demon.co.uk> writes:
Out of curiousity, how should (indeed, could!) they have implemented
accesskey without interfering with browser keyboard shortcuts?

By using some combo of accesskey with others (eg shift, ctrl, alt)
that isn't part of any builtin controls for the browser and platform.

Screen readers already use shift, alt and ctl combinations for their
commands.


What part of "eg" don't you understand?

Your point?

--
Jake
Jul 20 '05 #47

P: n/a
Brian <us*****@julietremblay.com.invalid-remove-this-part> wrote:
Karen McAtamney wrote:

What's the problem with accesskeys?
An accesskey that you define may already be a shortcut key in the
user's browser. In such a case, pressing that accesskey will have a
different result than keyboard users are accustomed to.


In Windows, you can invoke an application's Alt-shortcuts by hitting
the Alt key first, then hitting the character key. HTML shortcuts
require simultaneous pressing of the Alt and character key. Someone
who is aware that web pages can contain shortcuts can make a point of
pressing the keys in sequence to invoke browser-defined commands,
avoiding any conflict. Do other OSes, or browsers on other OSes,
provide a means for making this distinction?
- http://www.w3.org's accessibility guidelines specifically
recommends using them.


Just because the w3c says it, doesn't make it true.


Aye, there's the rub. What the W3C says is always in danger of
becoming required shop procedure.

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.
Jul 20 '05 #48

P: n/a
jake <ja**@gododdin.demon.co.uk> wrote:
In message <ld************@webthing.com>, Nick Kew
<ni**@hugin.webthing.com> writes
In article <wU**************@gododdin.demon.co.uk>,
jake <ja**@gododdin.demon.co.uk> writes:
> Out of curiousity, how should (indeed, could!) they have implemented
> accesskey without interfering with browser keyboard shortcuts?

By using some combo of accesskey with others (eg shift, ctrl, alt)
that isn't part of any builtin controls for the browser and platform.

Screen readers already use shift, alt and ctl combinations for their
commands.


What part of "eg" don't you understand?

Your point?


If a software manufacturer is dumb enough to choose a key combo that
is already in use then that's just their own stupidity. (Stand up
Microsoft and Mozilla...)

If you were building a browser or screen reader would you use
ALT+SHIFT+whatever to activate software functions and use
ALT+SHIFT+whatever to activate accesskeys?
No you'd use, for example, ALT+SHIFT for functions and ALT+CTRL for
accesskeys.

Opera gets it right, acceskeys are activated by SHIFT+ESC+whatever
which isn't used by any browser function at all.

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 20 '05 #49

P: n/a
Harlan Messinger wrote:
Brian wrote:
What's the problem with accesskeys?
An accesskey that you define may already be a shortcut key in the
user's browser. In such a case, pressing that accesskey will
have a different result than keyboard users are accustomed to.


In Windows, you can invoke an application's Alt-shortcuts by
hitting the Alt key first, then hitting the character key. HTML
shortcuts require simultaneous pressing of the Alt and character
key.


For those who know, that can be quite an impediment. Keyboard users
can be relentless quick on the peck of the key. Imagine someone wants
to change a setting in Mozilla: <alt-e>, and suddenly, they are on a
new page about entymology.
Someone who is aware that web pages can contain shortcuts can make
a point of pressing the keys in sequence to invoke browser-defined
commands, avoiding any conflict.


And someone's who's not aware will not know why e.g. alt-e does not
bring up their edit. Thus, the best advice is not to use them at all.

--
Brian (follow directions in my address to email me)
http://www.tsmchughs.com/

Jul 20 '05 #50

56 Replies

This discussion thread is closed

Replies have been disabled for this discussion.