Any advice?

[Alan J. Flavell]

Re: Any advice?

On Sat, 31 Jan 2004, jake wrote:
[color=blue]
> In message <Pine.LNX.4.53. 0401311430510.7 469@ppepc56.ph. gla.ac.uk>, Alan
> J. Flavell <flavell@ph.gla .ac.uk> writes[color=green]
> >
> >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.[/color]
>
> HPR/IE6.
>
> That's interesting. Which version did you test with?[/color]

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.
[color=blue]
> and what was it particularly about its handling of client-side maps
> that you didn't like?[/color]

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.
[color=blue]
> 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.[/color]

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

[Brian]

Re: Any advice?

Michael Wilcox wrote:[color=blue]
> brucie <shit@bruciesus enetshit.info> wrote:
>[color=green]
>> that would also result in it being hidden from a lot of screen
>> readers. makes the whole thing a bit pointless.[/color]
>
>
> What if media="screen"?[/color]

screen reader, not aural browser.

--
Brian (follow directions in my address to email me)

http://www.tsmchughs.com/

[Brian]

Re: Any advice?

Karen McAtamney wrote:[color=blue]
>
> What's the problem with accesskeys?[/color]

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.
[color=blue]
> - http://www.w3.org's accessibility guidelines specifically
> recommends using them.[/color]

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

--
Brian (follow directions in my address to email me)

http://www.tsmchughs.com/

[jake]

Re: Any advice?

In message <Pine.LNX.4.53. 0401311551070.7 469@ppepc56.ph. gla.ac.uk>, Alan
J. Flavell <flavell@ph.gla .ac.uk> writes[color=blue]
>On Sat, 31 Jan 2004, jake wrote:
>[color=green]
>> In message <Pine.LNX.4.53. 0401311430510.7 469@ppepc56.ph. gla.ac.uk>, Alan
>> J. Flavell <flavell@ph.gla .ac.uk> writes[color=darkred]
>> >
>> >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.[/color]
>>
>> HPR/IE6.
>>
>> That's interesting. Which version did you test with?[/color]
>
>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.
>[color=green]
>> and what was it particularly about its handling of client-side maps
>> that you didn't like?[/color]
>
>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.
>[color=green]
>> 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.[/color]
>
>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[/color]

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

[Nick Kew]

Re: Any advice?

In article <xlSSb.198861$n a.330904@attbi_ s04>,
Brian <usenet3@juliet remblay.com.inv alid-remove-this-part> writes:[color=blue]
> Karen McAtamney wrote:[color=green]
>>
>> What's the problem with accesskeys?[/color]
>
> 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.[/color]

Yep. A good idea botched by broken browser implementations .
[color=blue][color=green]
>> - http://www.w3.org's accessibility guidelines specifically
>> recommends using them.[/color]
>
> Just because the w3c says it, doesn't make it true.[/color]

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

[brucie]

Re: Any advice?

in post: <news:5qfn10dqr 2v1geasbfoe94su h0lfk7hqei@4ax. com>
Harlan Messinger <hmessinger.rem ovethis@comcast .net> said:
[color=blue][color=green][color=darkred]
>>>> that would also result in it being hidden from a lot of screen readers.
>>>> makes the whole thing a bit pointless.[/color][/color][/color]
[color=blue][color=green][color=darkred]
>>> If visibility: hidden; is used, yes.[/color][/color][/color]
[color=blue][color=green]
>>and display:none[/color][/color]
[color=blue][color=green][color=darkred]
>>> There are other positioning methods that a screen reader will ignore.[/color][/color][/color]
[color=blue][color=green]
>>it depends on the screen reader.[/color][/color]
[color=blue]
> z-index: -9;[/color]

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

[Alan J. Flavell]

Re: Any advice?

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

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.

[Harlan Messinger]

Re: Any advice?

brucie <shit@bruciesus enetshit.info> wrote:
[color=blue]
>in post: <news:5qfn10dqr 2v1geasbfoe94su h0lfk7hqei@4ax. com>
>Harlan Messinger <hmessinger.rem ovethis@comcast .net> said:
>[color=green][color=darkred]
>>>>> that would also result in it being hidden from a lot of screen readers.
>>>>> makes the whole thing a bit pointless.[/color][/color]
>[color=green][color=darkred]
>>>> If visibility: hidden; is used, yes.[/color][/color]
>[color=green][color=darkred]
>>>and display:none[/color][/color]
>[color=green][color=darkred]
>>>> There are other positioning methods that a screen reader will ignore.[/color][/color]
>[color=green][color=darkred]
>>>it depends on the screen reader.[/color][/color]
>[color=green]
>> z-index: -9;[/color]
>
>that may not work either, or positioning elements off the canvas area.
>as i said, it depends on the screen reader[/color]

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.

[brucie]

Re: Any advice?

in post: <news:bKAMgvLor 7GAFwZZ@gododdi n.demon.co.uk>
jake <jake@gododdin. demon.co.uk> said:
[color=blue]
> just replace the textual link with a link based on a
> 1-pixel image with its alternative text set to 'Skip Navigation'.[/color]

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

[brucie]

Re: Any advice?

in post: <news:si4o10hh5 vpe3e7bnd37cg7e qe9q9723qi@4ax. com>
Harlan Messinger <hmessinger.rem ovethis@comcast .net> said:
[color=blue][color=green]
>>that may not work either, or positioning elements off the canvas area.
>>as i said, it depends on the screen reader[/color][/color]
[color=blue]
> Too clever for their own good, eh?[/color]

its bloody annoying!
[color=blue]
> 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.[/color]

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

[Brian]

Re: Any advice?

Nick Kew wrote:[color=blue]
> In article <xlSSb.198861$n a.330904@attbi_ s04> Brian writes:
>[color=green]
>> 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.[/color]
>
> Yep. A good idea botched by broken browser implementations .[/color]

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/

[Nick Kew]

Re: Any advice?

In article <4sWSb.200212$n a.331329@attbi_ s04>,
Brian <usenet3@juliet remblay.com.inv alid-remove-this-part> writes:
[color=blue]
> Out of curiousity, how should (indeed, could!) they have implemented
> accesskey without interfering with browser keyboard shortcuts?[/color]

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

[Neal]

Re: Any advice?

On Sat, 31 Jan 2004 23:15:39 +0000, Nick Kew <nick@hugin.web thing.com>
wrote:
[color=blue]
> In article <4sWSb.200212$n a.331329@attbi_ s04>,
> Brian <usenet3@juliet remblay.com.inv alid-remove-this-part> writes:
>[color=green]
>> Out of curiousity, how should (indeed, could!) they have implemented
>> accesskey without interfering with browser keyboard shortcuts?[/color]
>
> 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.
>[/color]

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.

[jake]

Re: Any advice?

In message <rhpte1-7e7.ln1@webthin g.com>, Nick Kew
<nick@hugin.web thing.com> writes[color=blue]
>In article <4sWSb.200212$n a.331329@attbi_ s04>,
> Brian <usenet3@juliet remblay.com.inv alid-remove-this-part> writes:
>[color=green]
>> Out of curiousity, how should (indeed, could!) they have implemented
>> accesskey without interfering with browser keyboard shortcuts?[/color]
>
>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.
>[/color]
Screen readers already use shift, alt and ctl combinations for their
commands.

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

regards.

--
Jake

[jake]

Re: Any advice?

In message <bvh48u$shhp2$1 @ID-117621.news.uni-berlin.de>, brucie
<shit@bruciesus enetshit.info> writes[color=blue]
>in post: <news:bKAMgvLor 7GAFwZZ@gododdi n.demon.co.uk>
>jake <jake@gododdin. demon.co.uk> said:
>[color=green]
>> just replace the textual link with a link based on a
>> 1-pixel image with its alternative text set to 'Skip Navigation'.[/color]
>
>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.
>
>[/color]
Interesting ....... never come across that one before.

In that case, just make it a 6x1px transparent gif ;-)


--
Jake