[jaws-uk] Re: Finding specific text

  • From: Benjamin Hawkes-Lewis <bhawkeslewis@xxxxxxxxxxxxxx>
  • To: jaws-uk@xxxxxxxxxxxxx
  • Date: Mon, 05 Nov 2007 18:43:10 +0000

I'm another web developer not a JAWS user, so take what I say with a pinch of salt.


If you are a web developer who wants to gain an idea of JAWS's navigational abilities, I'd have a look at:

1. Juicy Studio: "Making Ajax Work with Screen Readers". This article includes an introduction to the different modes in which popular screen readers interact with HTML pages.
http://juicystudio.com/article/making-ajax-work-with-screen-readers.php

2. Surf's Up: Surfing the Internet with JAWS (an introductory tutorial):
http://www.freedomscientific.com/fs_products/Surfs_Up/_Surfs_Up_Start_Here.htm

3. The JAWS manual, available in Windows Help format from the following installer:
http://www.freedomscientific.com/fs_support/documentation/JAWS8_0Docs/JAWS80_HS.exe

If you're trying to make web content accessible with JAWS, you probably want to make it work with other popular screen readers too. Here's some more resources in vague order of popularity:

1. GW-Micro Window-Eyes 6.1 manual:
http://www.gwmicro.com/Window-Eyes/Manual/

2. Dolphin HAL manuals:
http://www.yourdolphin.com/supportmug.asp?id=5

3. Apple VoiceOver manual (for Tiger):
http://images.apple.com/accessibility/voiceover/pdf/VO_GettingStarted.pdf

4. NVDA documentation (NVDA is a FOSS Windows screen reader):
http://www.nvda-project.org/documentation.html

5. Thunder manuals (Thunder is free-for-personal-use Windows screen reader):
http://www.screenreader.net/index.php?pageid=13&section=Thunder%20and%20Manuals

6. Fire Vox (turns Firefox into a self-voicing app, particularly interesting because of its support for experimental ARIA properties like relevant: http://www.w3.org/TR/2007/WD-aria-state-20071019/#relevant):
http://clc4tts.clcworld.net/clc-firevox_doc.html

7. Orca documentation (Orca is the current GNOME screen reader):
http://live.gnome.org/Orca

8. Emacspeak (for Linux: turns Emacs, and its various web browsers, into a self-voicing app):
http://emacspeak.sourceforge.net/

To try and answer your question more directly, JAWS 8.0 introduced a feature precisely to skim read based on text attributes like boldness and color:

http://www.freedomscientific.com/fs_products/software_jaws80fea.asp#SkimReading

Window-Eyes 6.1 (don't know about earlier versions) has a similar feature:

http://www.gwmicro.com/Window-Eyes/Manual/HTML/index.html?section10_7.htm

But other screen readers don't necessarily have that feature, and earlier versions of JAWS certainly don't, which means you can't really rely on it in a public web application as many (perhaps most) users won't be able to do this.

I suspect it would be more reliable to use a textual hint like:

<li><a class="new">href="viewmsg?id=59690"><em class="new-hint">New: </em>Finding specific text</a></li>

Users could then search for "new" with standard Find and Find Next commands:

http://www.rnib.org.uk/xpedio/groups/public/documents/PublicWebsite/public_rnib003593.hcsp

If you don't want your average sighted user to see the word "new", you could hide the word off-screen left with CSS:

.new-hint {position:absolute;left:-9999%;}

http://www.w3.org/TR/WCAG20-CSS-TECHS/#C7

(/Pace/ the WCAG2 draft, I recommend off-left because hiding things off-top tends to make the Window-Eyes link list treat the hidden and visible components as separate links.)

Screen readers usually read text positioned off-screen in this way, but it's always worth checking with a developer's copy of Window-Eyes (http://www.gwmicro.com/Developers/) and/or by posting a test case to mailing lists like this one.

I'd tend to argue that a better approach, however, is to design an effective interface for the user-computer interaction that is taking place here rather than trying to add accessibility onto an existing visual interface. From what you're describing, the interaction could be summarized as "View relevant messages". A good interface for that might be to filter, sort, or group messages by relevancy, rather than forcing the user to do their own filtering, whether visually or by keyboard.

Hope that helps.

--
Benjamin Hawkes-Lewis

TIDDYogg wrote:
Here's the scenario:
You access an html page contianing a number of messages, say 100. A few of these may concern you. It is possible that the page can be so designed that these relevant messages appear either in bold or italic text, or maybe with a bullet or other identifier.

Now, can Jaws recognise such things, to jump to them, just like it will jump to the next button, or next heading - can it jump to the next bit of bold text etc?

If I can get this answered before any such implementation it will be much appreciated, so any suggestions/help gratefully received.


** To leave the list, click on the immediately-following link:-
** [mailto:jaws-uk-request@xxxxxxxxxxxxx?subject=unsubscribe]
** If this link doesn't work then send a message to:
** jaws-uk-request@xxxxxxxxxxxxx
** and in the Subject line type
** unsubscribe
** For other list commands such as vacation mode, click on the
** immediately-following link:-
** [mailto:jaws-uk-request@xxxxxxxxxxxxx?subject=faq]
** or send a message, to ** jaws-uk-request@xxxxxxxxxxxxx with the Subject:- faq



** To leave the list, click on the immediately-following link:-
** [mailto:jaws-uk-request@xxxxxxxxxxxxx?subject=unsubscribe]
** If this link doesn't work then send a message to:
** jaws-uk-request@xxxxxxxxxxxxx
** and in the Subject line type
** unsubscribe
** For other list commands such as vacation mode, click on the
** immediately-following link:-
** [mailto:jaws-uk-request@xxxxxxxxxxxxx?subject=faq]
** or send a message, to ** jaws-uk-request@xxxxxxxxxxxxx with the Subject:- faq

Other related posts: