E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 3 (In chronological order)

From: Oliver Boermans
Date: Wed, Jun 28 2006 1:00AM
Subject: Screenreader testing a JavaScript 'enhanced' page
No previous message | Next message →

Hi All

Firstly - because a demo is worth a thousand words (Click on an orange link):
<http://www.ollicle.com/eg/inline-glossary/>;

The purpose of the JavaScript in this page is to make finding the
definition of certain words less disruptive to reading. Clicking on a
term (orange link) pops up a description directly underneath the word.
Without the script these links point to glossary at the bottom of the
page.

Screenreader users are particularly important to my accessibility
conscious client <http://www.novita.org.au>;. I have been attempting to
test this functionality using JAWS with Internet Explorer with mixed
results. It's difficult for me to know to what degree my problems can
be attributed to my JAWS operator deficiencies or otherwise. I was
surprised for instance that JAWS did not read my carefully included
title attributes!

So basically I'm after feedback from people who are more accustomed to
designing for or using JAWS or similar software.

The latest version of the demo page is here:
<http://www.ollicle.com/eg/inline-glossary/v1/>;

It seems to me that a method similar to what I have used here for
'hiding' inline content could have numerous applications - providing
it can be made reliably accessible?

Cheers Ollie

From: ben morrison
Date: Wed, Jun 28 2006 3:10AM
Subject: Re: Screenreader testing a JavaScript 'enhanced' page
← Previous message | Next message →

On 6/28/06, Oliver Boermans < = EMAIL ADDRESS REMOVED = > wrote:
> Hi All
>
> Firstly - because a demo is worth a thousand words (Click on an orange link):
> <http://www.ollicle.com/eg/inline-glossary/>;
>
> The purpose of the JavaScript in this page is to make finding the
> definition of certain words less disruptive to reading. Clicking on a
> term (orange link) pops up a description directly underneath the word.
> Without the script these links point to glossary at the bottom of the
> page.

Instead of pointing to the glossary these links should point to the
actual description of the term

So : <a href="#glossary">eligible</a>

should instead of pointing to the glossary point to this

<dt><span><a id="eligible"></a></span>eligible</dt>

but would be better coded as

<a href="#eligible">eligible</a>

<dt id="eligible">eligible</dt>

Jaws does not read the title attribute by default - unless in forms mode.

Ben

From: Oliver Boermans
Date: Wed, Jun 28 2006 4:10AM
Subject: Re: Screenreader testing a JavaScript 'enhanced' page
← Previous message | No next message

Good point - it would certainly be better to have more specific
anchors to fall back on. The glossary anchors are legacy from our
attempt (5 years ago now!) to make it as simple as possible for the
client to mark-up the terms in the WYSIWYG of the content management
system. Call it laziness if you like. I imagine we could fix their
existing content with some clever search and replace...

The purpose behind the ugly anchors (with spans etc) is a workaround
for bugs in IE and Firefox. If there is a cleaner way around these
problems I'd love to hear about it:

- IE has problems when you navigate page anchors with the keyboard in
certain circumstances:
See links on this page
<http://wiki.jalakai.co.uk/css-demos/ie-keyboard-navigation>;

- I read somewhere (I've lost the link) that Firefox only jumps
reliably to <a> elements from an anchor. Worth retesting this one I
guess.

Further reading has enlightened me a little more about how JAWS works:
<http://juicystudio.com/article/making-ajax-work-with-screen-readers.php>;

Switching off the Virtual PC Cursor [insert z] causes JAWS to behave
more like I expected (reading titles etc), but it's functionality
appears to be significantly diminished. I take it forms mode is the
only way of triggering this kind of behaviour without asking the user
to switch manually?

I'm beginning to think that maybe it doesn't matter if the titles are
not read with this particular example. Perhaps linking the word is
sufficient context in itself?

What concerns me is what happens (with JavaScript enabled) when a
non-sighted user follows a linked term. Right now that seems to depend
on what mode the screenreader is in.

On 6/28/06, ben morrison < = EMAIL ADDRESS REMOVED = > wrote:
> On 6/28/06, Oliver Boermans < = EMAIL ADDRESS REMOVED = > wrote:
> > Hi All
> >
> > Firstly - because a demo is worth a thousand words (Click on an orange link):
> > <http://www.ollicle.com/eg/inline-glossary/>;
> >
> > The purpose of the JavaScript in this page is to make finding the
> > definition of certain words less disruptive to reading. Clicking on a
> > term (orange link) pops up a description directly underneath the word.
> > Without the script these links point to glossary at the bottom of the
> > page.
>
> Instead of pointing to the glossary these links should point to the
> actual description of the term
>
> So : <a href="#glossary">eligible</a>
>
> should instead of pointing to the glossary point to this
>
> <dt><span><a id="eligible"></a></span>eligible</dt>
>
> but would be better coded as
>
> <a href="#eligible">eligible</a>
>
> <dt id="eligible">eligible</dt>
>
> Jaws does not read the title attribute by default - unless in forms mode.
>
> Ben