E-mail List Archives
Thread: IBM Home Page Reader
Number of posts in this thread: 11 (In chronological order)
From: Glenda Watson Hyatt
Date: Tue, Oct 16 2001 1:57PM
Subject: IBM Home Page Reader
No previous message | Next message →
I've downloaded the demo version of IBM Home Page Reader to gain a better
understand of how screen readers actually sound. Quite an eye opener.
I am wondering if IBM HPR is a fair representation of screen readers. The
reason I ask is that it didn't seem to handle data tables as I expected.
Cell headers weren't linked with cell data. Is there a HPR setting I need
to change? Or, doesn't HPR work this way? I'd appreciate insight here.
And, while I'm here, according to WAI:
Labels for radio buttons and checkboxes should appear after the radio button
or checkbox. For example:
Choose your area of interest:
[] Personal Development [] Management Skills
Have I interpreted this correctly? Why have the checkbox before hearing
what you are checking? Or, do I have something wrong? Thanks.
Cheers,
Glenda
PS Can anyone explain why IBM HPR needs Microsoft IE to operate? Is IBM in
bed with Microsoft??
*********
Glenda Watson Hyatt
Soaring Eagle Communications
"Creating freedom and power through accessible communications"
E Mail: mailto: = EMAIL ADDRESS REMOVED =
Website: http://www.eaglecom.bc.ca
Want to know how to make your website accessible to more people?
Subscribe to our FREE newsletter by emailing
mailto: = EMAIL ADDRESS REMOVED =
*********
---
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Joel Ward
Date: Tue, Oct 16 2001 2:21PM
Subject: RE: IBM Home Page Reader
← Previous message | Next message →
Hi Glenda,
From what I have heard and read, none of the three major screen readers
(JAWS, WindowEyes and HPR) properly associate headers with cell data (using
id/headers) or read the scope attributes.
However, these two methods are the only way that the Access Board has
suggested for making tables accessible and Section 508 compliant. See:
http://www.access-board.gov/sec508/guide/1194.22.htm#(g)
I am also curious if there is a way for any of the screen readers to process
these accessible table attributes. If not, will they be compliant with the
standards? When? Or is it a web browser issue? (Is IE at fault or the
assistive technology?)
These attributes would be great way to make our HTML pages easier to read
for all users IF the user agents could understand them properly.
For the meantime, I will continue to code with the id/headers or scope
attributes in my tables, even though I cannot test their functionality.
Does anyone have more information?
Joel
----- Original Message -----
From: "Glenda Watson Hyatt" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM accessibility forum" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, October 16, 2001 3:53 PM
Subject: IBM Home Page Reader
> I've downloaded the demo version of IBM Home Page Reader to gain a better
> understand of how screen readers actually sound. Quite an eye opener.
>
> I am wondering if IBM HPR is a fair representation of screen readers. The
> reason I ask is that it didn't seem to handle data tables as I expected.
> Cell headers weren't linked with cell data. Is there a HPR setting I need
> to change? Or, doesn't HPR work this way? I'd appreciate insight here.
>
> And, while I'm here, according to WAI:
>
> Labels for radio buttons and checkboxes should appear after the radio
button
> or checkbox. For example:
>
> Choose your area of interest:
> [] Personal Development [] Management Skills
>
> Have I interpreted this correctly? Why have the checkbox before hearing
> what you are checking? Or, do I have something wrong? Thanks.
>
> Cheers,
> Glenda
>
>
> PS Can anyone explain why IBM HPR needs Microsoft IE to operate? Is IBM
in
> bed with Microsoft??
>
> *********
> Glenda Watson Hyatt
> Soaring Eagle Communications
> "Creating freedom and power through accessible communications"
> E Mail: mailto: = EMAIL ADDRESS REMOVED =
> Website: http://www.eaglecom.bc.ca
> Want to know how to make your website accessible to more people?
> Subscribe to our FREE newsletter by emailing
> mailto: = EMAIL ADDRESS REMOVED =
>
> *********
>
>
>
>
> ---
> To subscribe, unsubscribe, or view list archives,
> visit http://www.webaim.org/discussion/
>
>
---
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Paul Bohman
Date: Tue, Oct 16 2001 2:32PM
Subject: RE: IBM Home Page Reader
← Previous message | Next message →
The latest versions of both JAWS and HPR read the headers just fine when you go into table reading mode. For Home Page Reader (HPR), you hit ALT+T, then use the arrows to navigate between cells. In JAWS, you hit CTRL+ALT+arrows to navigate between cells. JAWS does have a fatal flaw though: if you have spanned columns or rows, it will associate the wrong headers with the cells. HPR does not have this problem. As long as you don't have spanned cells, both read the tables very well. I have less experience with Window Eyes, so I can't speak to that directly.
Paul Bohman
Technology Coordinator
WebAIM (Web Accessibility in Mind)
www.webaim.org
Utah State University
www.usu.edu
From: Kynn Bartlett
Date: Tue, Oct 16 2001 2:32PM
Subject: Re: IBM Home Page Reader
← Previous message | Next message →
At 12:53 PM -0700 2001/10/16, Glenda Watson Hyatt wrote:
>I've downloaded the demo version of IBM Home Page Reader to gain a better
>understand of how screen readers actually sound. Quite an eye opener.
>I am wondering if IBM HPR is a fair representation of screen readers.
HPR isn't a screenreader, though. A screenreader is software that
typically sits just above the operating system level, and can read out
any text that appears on the screen. It can also read text equivalents
if those are encoded into the GUI API -- such as Microsoft's
Active Accessibility, or Sun's Java accessibilty API.
HPR is a browser that talks -- it doesn't sit directly above the
operating system, but is rather a single application that runs, and
when it runs, it talks.
This isn't saying HPR is bad or isn't a great tool for web authors.
In fact, I highly recommend it in my online course. However, it's not
a screenreader like JAWS (for example). On the other hand, JAWS is
likely overkill for a sighted web developer, and there is a high
learning curve which frankly most people will not undertake unless
they _have_ to. HPR is easier to learn, but it does less, since it
is just a browser that talks.
By the way, when using it, please make SURE that you turn off your
monitor or else you will get a _very_ distorted picture of how HPR
really works. Vision is a crutch, and a deceptive one, for web
authors who want to test with a screenreader or a talking browser.
>PS Can anyone explain why IBM HPR needs Microsoft IE to operate? Is IBM in
>bed with Microsoft??
Nah, there's not really a "bedding" phenomenon here. The real reasons
are technical -- Microsoft has distributed their core "parser" for
IE in such a way that anyone who wants to can write their own front
end, and access the information in the web pages programmatically
via API. This makes it amazingly easy (well, comparatively) to write
special purpose browsers with IE's parser as a base.
Why not use Netscape? Early versions of HPR did -- but the problem
was that Netscape simply does not have the API, either in the parser
or at the OS level, to allow it to be used in such a manner easily.
This is why IE is the "parser of choice" and Netscape is not. Mozilla
hasn't been much better than Netscape.
Say what you will about Microsoft, but their commitment to accessibility
while far from perfect, is better than nearly anything out there. Which
is less of praise for Microsoft's efforts than an overall lament on
the state of assistive technology. Microsoft is "the" platform from
a technical sense just because they're the only ones who bothered to
do anything -- it's worse if you look at Apple, Linux, Netscape, AOL,
etc.
IBM, of course, deserves a lot of praise themselves for HPR and other
excellent efforts at promoting accessibility through software products,
and Sun for Java accessibility. I hope nobody feels left out. :)
--Kynn
--
Kynn Bartlett < = EMAIL ADDRESS REMOVED = >
http://www.kynn.com/
---
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Paul Bohman
Date: Tue, Oct 16 2001 3:05PM
Subject: Re: IBM Home Page Reader
← Previous message | Next message →
Kynn's right when he says HPR isn't a screenreader. HPR is slightly more
than "a browser that talks" though. Not only does it read web pages, but it
can also read Notepad (e.g. when you view the source of web pages) and email
(it has a built-in email program, which I've never used personally). Maybe
you could call it an "Disability-Accessible Internet Connectivity Software
Suite" or something else equally grand and overly verbose <smile/>.
I want to echo Kynn's recommendation of HPR for Web developers. It is an
excellent piece of software, in some ways superior to JAWS, but in most ways
comparable. I use if often when testing web pages. It's definitely less
expensive than JAWS. HPR is abot $120 and JAWS is about $800 or
$1200(Win95/98/Me versus NT/200 price).
You can, however, download the trial version of JAWS which has a half-hour
time limit on usage. You can use it for up to half an hour, then you have to
reboot your computer to get it to work again. Sometimes this is sufficient
for Web developers. As far as I know, you can keep rebooting your computer
as long as you want. I don't think there is an expiration date on the trial
version.
There is also a scaled-down version of JAWS called Connect Outloud, which
retails for about $250. This is similar to HPR in that it is limited to
browsing the web and accessing email--but Connect Outloud does read the
desktop and Windows Explorer, which HPR does not. You can't read Word files,
or anything else like that with Connect Outloud. Only the full version of
JAWS can access Adobe PDF files (and this is only feasible in Adobe Acrobat
5.0, the latest version, and only if the PDF file was created accessibly;
see http://access.adobe.com for more info). [but that's another topic
entirely]
Paul Bohman
Technology Coordinator
WebAIM (Web Accessibility in Mind)
www.webaim.org
Utah State University
www.usu.edu
---
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Glenda Watson Hyatt
Date: Tue, Oct 16 2001 3:44PM
Subject: Re: IBM Home Page Reader
← Previous message | Next message →
Thanks Kynn and Paul, I do appreciate that HPR is not a "screen reader", but
for a sighted individual (my eyes are one of the few parts that work on this
body!) if it does a fair representation of simulating a screen reader for
the sole purpose of assessing web accessibility, then I may be tempted to
buy it at $120US (roughly $180CAD) rather than JAWS at $1200US ($1800CAD).
Cheers,
Glenda
*********
Glenda Watson Hyatt
Soaring Eagle Communications
"Creating freedom and power through accessible communications"
E Mail: mailto: = EMAIL ADDRESS REMOVED =
Website: http://www.eaglecom.bc.ca
Want to know how to make your website accessible to more people?
Subscribe to our FREE newsletter by emailing
mailto: = EMAIL ADDRESS REMOVED =
*********
>
From: Kynn Bartlett
Date: Tue, Oct 16 2001 5:04PM
Subject: Re: IBM Home Page Reader
← Previous message | Next message →
At 2:40 PM -0700 2001/10/16, Glenda Watson Hyatt wrote:
>Thanks Kynn and Paul, I do appreciate that HPR is not a "screen reader", but
>for a sighted individual (my eyes are one of the few parts that work on this
>body!) if it does a fair representation of simulating a screen reader for
>the sole purpose of assessing web accessibility, then I may be tempted to
>buy it at $120US (roughly $180CAD) rather than JAWS at $1200US ($1800CAD).
That is my recommendation -- HPR is an excellent tool for analysis
for use by web developers.
(I have no opinion on how good it functions as a tool for people with
disabilities! I don't feel qualified to speak on that topic.)
--Kynn
--
Kynn Bartlett < = EMAIL ADDRESS REMOVED = >
http://www.kynn.com/
---
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Joel Ward
Date: Tue, Oct 16 2001 6:10PM
Subject: Re: IBM Home Page Reader
← Previous message | Next message →
Hi Paul,
Thanks for the info!
Does JAWS and HPR associate the id and headers attributes of the TH and TD
cells, or the scope attributes of the TH cells? Or do these programs
"automatically" associate headers with cells?
The Access Board suggested that we use these attributes, which I think are
great in theory. Just curious whether they are used in practice.
Joel
----- Original Message -----
From: "Paul Bohman" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM forum" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, October 16, 2001 4:26 PM
Subject: RE: IBM Home Page Reader
> The latest versions of both JAWS and HPR read the headers just fine when
you
> go into table reading mode. For Home Page Reader (HPR), you hit ALT+T,
then
> use the arrows to navigate between cells. In JAWS, you hit CTRL+ALT+arrows
> to navigate between cells. JAWS does have a fatal flaw though: if you have
> spanned columns or rows, it will associate the wrong headers with the
cells.
> HPR does not have this problem. As long as you don't have spanned cells,
> both read the tables very well. I have less experience with Window Eyes,
so
> I can't speak to that directly.
>
> Paul Bohman
> Technology Coordinator
> WebAIM (Web Accessibility in Mind)
> www.webaim.org
> Utah State University
> www.usu.edu
>
>
From: Paul Bohman
Date: Tue, Oct 16 2001 8:30PM
Subject: Re: IBM Home Page Reader
← Previous message | Next message →
Yes, JAWS and HPR associate the id and headers attributes of the TH and TD
cells. HPR also supports the "scope" attributes of the TH cells.
JAWS does not seem to support the scope attribute, but this may not be a
problem with most tables, because JAWS makes a guess and reads the first
cell at the top of the column (when in table reading mode) as if it did have
the scope attribute marked up. Complex tables may not be read correctly by
JAWS unless you use the headers attribute. For simple tables, though, the
scope attribute will suffice, in my opinion.
HPR supports the abbr within header cells. For example, if you have a header
cell with a long heading (e.g. "Husbands or Wives of past university
presidents"), you could abbreviate it like this: abbr="spouses". This makes
it less tiresome to listen to over and over again. JAWS does not support the
abbr within header cells. I would still go ahead and use abbr where
appropriate, though. It will benefit HPR users and someday (hopefully) it
will benefit JAWS users as well.
If you don't use either the "headers" or "scope" attributes, the tables may
not be read correctly.
Here is an example of a table with scope attributes and abbr attributes
(several lines of html follow):
<table width="80%" border="1" cellspacing="2" cellpadding="6">
<caption>Staff Directory for Pretend Company</caption>
<!-- TABLE HEADERS -->
<tr>
<td></td>
<th scope="col" abbr="Title">Job Title</th>
<th scope="col" abbr="Room">Room Number</th>
<th scope="col">Building</th>
<th scope="col" abbr="Phone">Phone Number</th>
<th scope="col" abbr="E-mail">E-mail Address</th>
</tr>
<!-- FIRST ROW -->
<tr>
<th scope="row">Gloria Garcia</th>
<td>Web Developer</td>
<td align=center>17</td>
<td>Blue</td>
<td>555-1234</td>
<td> = EMAIL ADDRESS REMOVED = </td>
</tr>
<!-- SECOND ROW -->
<tr>
<th scope="row">Jan Frank</th>
<td>Web Developer</td>
<td align=center>93</td>
<td>Purple</td>
<td>555-7089</td>
<td> = EMAIL ADDRESS REMOVED = </td>
</tr>
<!-- THIRD ROW -->
<tr>
<th scope="row">James Michiko</th>
<td>Web Designer</td>
<td align=center>20</td>
<td>Blue</td>
<td>555-3424</td>
<td> = EMAIL ADDRESS REMOVED = </td>
</tr>
<!-- FOURTH ROW -->
<tr>
<th scope="row"> Rao Mitchell</th>
<td>Web Accessibility Coordinator</td>
<td align=center>45</td>
<td>Blue</td>
<td>555-1243</td>
<td> = EMAIL ADDRESS REMOVED = </td>
</tr>
<!-- FIFTH PERSON -->
<tr>
<th scope="row">Marama Smith</th>
<td>Web Manager</td>
<td align=center>230</td>
<td>Green</td>
<td>555-7389</td>
<td> = EMAIL ADDRESS REMOVED = </td>
</tr>
Paul Bohman
Technology Coordinator
WebAIM (Web Accessibility in Mind)
www.webaim.org
Utah State University
www.usu.edu
---
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Paul Bohman
Date: Tue, Oct 16 2001 8:35PM
Subject: Re: IBM Home Page Reader
← Previous message | Next message →
Just as a side note, Home Page Reader can also read Real Player menus. Real
Player itself is semi-accessible. See
http://www.webaim.org/Articles/embeddedmp.
Paul Bohman
Technology Coordinator
WebAIM (Web Accessibility in Mind)
www.webaim.org
Utah State University
www.usu.edu
---
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Paul Bohman
Date: Tue, Oct 16 2001 9:52PM
Subject: Re: IBM Home Page Reader
← Previous message | No next message
Although this question was asked off the list, I would like to provide a
brief response on the list:
question:
Do you have or know of a list of tags/attributes that each of the major AT's
support?
answer:
Although I have been wanting to compile such a list for quite some time now,
I still have not done so, and I know of no other such list. Here is a
general answer though:
With few exceptions, the latest versions of the major screen readers and
so-called "talking browsers" support nearly all of the W3C recommendations.
Label tags and fieldset tags for form input elements work well. Table
headers work (as long as you don't use rowspan or colspan), alt attributes
for images work, headings work (e.g. <h1>), and other elements.
Here are the exceptions that I can think of off hand:
1. Table Headers don't work properly in JAWS if there are rowspans or
colspans
2. It seems that the "name" attribute of frames is read instead of the
"title" attribute when both are present. It is possible that the latest
versions of the software have corrected this, but I have not checked for a
while.
3. Longdesc is sort of supported, but not satisfactorily, in my opinion, so
I still recommend providing some other means of providing longer
descriptions for images. Usually this means providing a "d" link (which
stands for "description" or "descriptive" link) to an external file. A "d"
link is nothing more than the letter d, as a hyperlink, placed after an
image. The link destination is a separate file with a longer description of
the image.
4. The abbr tag is not supported by JAWS.
5. The optgroup tag (within form drop-down lists) is not well supported.
This is largely the browsers' fault.
6. I have had trouble with very complex tables, with rowgroup and colgroup.
I'm not sure that these are supported yet.
7. Aural style sheets are not supported (that I know of). Aural style sheets
would allow web authors to specify the voice inflection, voice type,
loudness, softness, etc. of speech software.
Despite the fact that there are certain things which are not yet supported,
nearly all of the common elements are already supported. Don't get
discouraged when you look at the above list. There may be a couple of things
on this list that affect you, but chances are that most of them don't, at
this point. Assistive technologies are continually improving. They have made
life liveable for millions of individuals, despite the shortcomings that
they may have. Of course there is always room for improvement.
From a web developer's perspective: don't be afraid to use the standards.
With few exceptions, they are supported.
Paul Bohman
Technology Coordinator
WebAIM (Web Accessibility in Mind)
www.webaim.org
Utah State University
www.usu.edu
---
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/