E-mail List Archives

You are here: Home > Community > E-mail List Archives > View Thread

Thread: Proper mark-up (was Re: Speech output for a Trip Planner)

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

From: Keith Parks
Date: Fri, Jun 06 2008 11:10AM
Subject: Proper mark-up (was Re: Speech output for a Trip Planner)
No previous message | Next message →

On Jun 6, 2008, at 9:30 AM, Jennifer Sutton wrote:

> To bring the subject back to trip planners, I will not claim that
> it's perfect, but I find:
> www.511.org
>
> quite usable and useful with my screen reader of choice, Window-Eyes.
>

I find it interesting that you describe 511.org as usable and useful.

I took a quick look at a couple of random pages off of the top menu,
"Transit > List of Transit Providers" and "Transit > All Nighter Bus
Service", and noticed that little to none of the main content on
either of those pages is marked up with the kind of structural
elements that we are so often reminded is *key* to having the content
be "usable".

For instance,there are no <h> levels tags. Subheads are wrapped in
STRONG and sized up through a "class=titlelarge" span. A number of
sections that ought to be lists are just paragraphs with line returns.

Not that I plan on abandoning proper structural mark-up, but I would
have thought that a site like this would have been considered a
textbook case of failure in terms of accessibility/usability,
particularly for a screen reader. Clearly, for someone at least, it
is not.

******************************
Keith Parks
Graphic Designer/Web Designer
Student Affairs Communications Services
San Diego State University
San Diego, CA 92182-7444
(619) 594-1046
mailto: = EMAIL ADDRESS REMOVED =
http://www.sa.sdsu.edu/communications

http://kparks.deviantart.com/gallery
----------------------------------------------------------

World Peace through Cascading Style Sheets.

From: Jennifer Sutton
Date: Fri, Jun 06 2008 1:10PM
Subject: Re: Proper mark-up (was Re: Speech output for a Trip Planner)
← Previous message | Next message →

Keith and all:

This will teach me to post about a site without carefully re-looking
at it, first.

Sorry, folks. I guess this is a textbook case of:
"when you need what a site has to offer, you make it work." And
"if you find what you need, then maybe you don't remember very
clearly what it took to get at the info."

This is a reminder for me that I surf with two parts of my brain --
the tester part and the "get the job done" part.

Clearly, only one part of that combination has been engaged when I
have used this site.

So, it's far from perfect . . . very far.

Proper markup is good -- ALWAYS good!

Jennifer
At 10:03 AM 6/6/2008, you wrote:

>On Jun 6, 2008, at 9:30 AM, Jennifer Sutton wrote:
>
> > To bring the subject back to trip planners, I will not claim that
> > it's perfect, but I find:
> > www.511.org
> >
> > quite usable and useful with my screen reader of choice, Window-Eyes.
> >
>
>I find it interesting that you describe 511.org as usable and useful.
>
>I took a quick look at a couple of random pages off of the top menu,
>"Transit > List of Transit Providers" and "Transit > All Nighter Bus
>Service", and noticed that little to none of the main content on
>either of those pages is marked up with the kind of structural
>elements that we are so often reminded is *key* to having the content
>be "usable".
>
>For instance,there are no <h> levels tags. Subheads are wrapped in
>STRONG and sized up through a "class=titlelarge" span. A number of
>sections that ought to be lists are just paragraphs with line returns.
>
>Not that I plan on abandoning proper structural mark-up, but I would
>have thought that a site like this would have been considered a
>textbook case of failure in terms of accessibility/usability,
>particularly for a screen reader. Clearly, for someone at least, it
>is not.
>
>******************************
>Keith Parks
>Graphic Designer/Web Designer
>Student Affairs Communications Services
>San Diego State University
>San Diego, CA 92182-7444
>(619) 594-1046
>mailto: = EMAIL ADDRESS REMOVED =
>http://www.sa.sdsu.edu/communications
>
>http://kparks.deviantart.com/gallery
>----------------------------------------------------------
>
>World Peace through Cascading Style Sheets.
>
>
>

From: Benjamin Hawkes-Lewis
Date: Sun, Jun 08 2008 4:10AM
Subject: Re: Speech output for a Trip Planner Table
← Previous message | Next message →

Tom Kort wrote:
> I am working on the accessibility of trip planners.

Trip planners are notorious for accessibility problems. Would you mind
explaining in what capacity you are working on them? Are you developing
one? Testing one?

> In my work I am currently using the Job Access to Work (JAWS) screen
> reader program on the Vancouver translink.bc.ca website.

A link to the precise page, or a description of how to get there, would
be helpful. Are you talking about:

http://tripplanning.translink.bc.ca/

Also, is this trip planner a planner you are developing, retrofitting,
or simply one you are using as an example for your own work?

Some (slightly) better examples you might like to look at include:

http://journeyplanner.tfl.gov.uk/

http://traintimes.org.uk/

> When I access the trip planner for Translink I get something like:

> A readout of the top navigation bar ("link graphic bus schedules nav
> slash five", etc) A readout of the main graphic ("link graphic South
> Coast British Columbia Transportation Authority") A readout of the
> bottom navigation bar ("link graphic home nav slash five", etc)
> ....readout of some more graphics... A readout of the table name A
> readout of the headers ("link graphic trip options, link graphic
> start, link graphic trip end", etc.) A readout of the first table
> row: "Detail Expo Line 5 15p 5 19p 4min 00 point 62 k m dollar 2
> point 5 0" The output I ultimately want is "Press for Details,
> Transit Line Expo Line, Trip Start 5 15pm, Trip End 5 19pm, Duration
> 4 min, Transfers 0, Walk 0 point 62km, dollar 2 point 5 0"
>
>
> Question. Is there a good method to produce my desired speech output?
>
While it's reasonable to think about aural rendering on a micro
level, e.g. how different date and time formats are read, your focus on
a macro level needs to be on strategies users with different abilities
employ to navigate the web, the transactions a given web resource is
intended to facilitate, and how the features provided by the web
technology stack, taking into account both specifications and
implementations, can best support them.

W3C's "How People with Disabilities Use the Web" is a good starting point:

http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/Overview.html

as is the BBC Access 2.0 blog's series of interviews with people with
disabilities:

http://tinyurl.com/6k2zsq

I'd recommend the following videos about how people use assistive
technology:

http://del.icio.us/benjaminhawkeslewis/video%2BuserStrategies%2Bdisabled

Doug Geoffray's talk on screen reader technology is also useful:

Doug Geoffray: From the Mouth of a Screenreader (Part 1)
http://video.yahoo.com/watch/357221

Doug Geoffray: From the Mouth of a Screenreader (Part 2)
http://video.yahoo.com/watch/357221

I'd recommend looking through draft WCAG 2.0 as a starting point guide
to using web features to meet those needs:

http://www.w3.org/WAI/intro/wcag20

There are good introductory guides to form and table accessibility
issues on the WebAIM site:

http://www.webaim.org/techniques/forms/

http://www.webaim.org/techniques/tables/

In terms of complex forms programming, perhaps the most important
additional insight is to keep instructions for using a form in fieldset
legends or field labels or field TITLE attributes or before the FORM
element, since if you place it elsewhere inside the FORM element (in a
heading or paragraph element for example) it may be missed entirely if a
JAWS user moves from form control to form control in JAWS forms mode (or
the equivalent in other screen readers).

Finally, involve end-users in testing your solution by asking on
end-user discussion groups:

Freedom Scientific JAWS users:
= EMAIL ADDRESS REMOVED =
http://www.freelists.org/list/jfw

Dolphin HAL users:
= EMAIL ADDRESS REMOVED =
http://tech.groups.yahoo.com/group/dolphinusers/

GW-Micro Window-Eyes users:
= EMAIL ADDRESS REMOVED =
http://www.gwmicro.com/Support/GW-Info_Archives/

Apple VoiceOver users:
= EMAIL ADDRESS REMOVED =
http://www.freelists.org/list/macvoiceover/

GNOME Orca users:
= EMAIL ADDRESS REMOVED =
http://mail.gnome.org/mailman/listinfo/orca-list

NVDA users:
= EMAIL ADDRESS REMOVED =
http://www.freelists.org/list/nvda

Thunder users:
= EMAIL ADDRESS REMOVED =
http://www.freelists.org/list/thunder

> Can JAWS or any other popular screen reader program filter out the
> "p" on the time (5:19p)?

Why is there a "p" there in the first place? What does it mean? Why
isn't it correctly written as "5.19 p.m."?

> Can JAWS read the column of a table as it traverses a row?

There's a good introduction to JAWS's table navigation facilities at:

http://www.freedomscientific.com/fs_products/Surfs_Up/Tables.htm

The manual has further details under the "HTML Tables" topic, including
the following:

> When you move to the next or prior cell in the same row using table
> navigation commands such as ALT+CTRL+RIGHT ARROW, JAWS reads the
> column header and the data in the cell and announces the column
> number.

http://www.freedomscientific.com/fs_support/doc_screenreaders.asp

Tom continues:

> One weird thing happens... When I get the trip planner results,
> sometimes I get the readout of the previous page, instead of the
> current page, Why is this?

To answer this, we'd need instructions on how to reproduce the problem.
If I had to guess, I suspect that the page was actually being
dynamically updated by JS in a way that does not cause JAWS to update
its virtual buffer. See discussions (from various points of view) at:

http://del.icio.us/benjaminhawkeslewis/ajax%2BscreenReaders

--
Benjamin Hawkes-Lewis

From: Benjamin Hawkes-Lewis
Date: Sun, Jun 08 2008 4:20AM
Subject: Re: Speech output for a Trip Planner Table
← Previous message | Next message →

From: Tom Kort
Date: Sun, Jun 08 2008 6:10PM
Subject: Re: Speech output for a Trip Planner Table
← Previous message | Next message →

>Trip planners are notorious for accessibility problems. Would you mind
>explaining in what capacity you are working on them? Are you developing
>one? Testing one?
 
I am testing the trip planner at http://tripplanning.translink.bc.ca/hiwire
I would like to know some of the specific notorious aspects of trip planners, since people are suggesting that I ammicromanaging my accessibility approach.

>A link to the precise page, or a description of how to get there, would
>?be helpful. Are you talking about:

You can access the trip planner by
1. visiting http://tripplanning.translink.bc.ca/hiwire
2.  Under the "From" fields, choose an arbitrary location from "Select from Popular Locations". Then pick an arbitrary location from "Here are the locations available in the category. Please select one."
3. Under the "To" fields, choose an arbitrary location from "Select from Popular Locations."
Then pick an arbitrary location from "Here are the locations available in the category. Please select one."
4. Press "Next Step"

>Also, is this trip planner a planner you are developing, retrofitting,
>or simply one you are using as an example for your own work?
 
I am retrofitting the trip planner on the Translink site.
 
Thank you for the example websites.
 
-Michael Ohene

From: Benjamin Hawkes-Lewis
Date: Mon, Jun 09 2008 5:50PM
Subject: Re: Speech output for a Trip Planner Table
← Previous message | No next message

Tom Kort wrote:
> I am testing the trip planner at http://tripplanning.translink.bc.ca/hiwire
> I would like to know some of the specific notorious aspects of trip
> planners, since people are suggesting that I ammicromanaging my
> accessibility approach.

Hi Tom, attention to detail in accessibility testing is good. :) I think
people are rather suggesting you're trying to micromanage how a
screenreader reads the page, rather than trying to give a screenreader
user as much flexibility as possible to read the page as suits them.

I'm not sure that trip planners have accessibility problems that are
intrinsic to trip planners, rather than generally tending to be examples
of inaccessible design and implementation.

> >A link to the precise page, or a description of how to get there, would
> >?be helpful. Are you talking about:
>
> You can access the trip planner by
>
> 1. visiting http://tripplanning.translink.bc.ca/hiwire
> 2. Under the "From" fields, choose an arbitrary location from "Select
> from Popular Locations". Then pick an arbitrary location from "Here are
> the locations available in the category. Please select one."
>
> 3. Under the "To" fields, choose an arbitrary location from "Select from
> Popular Locations."
>
> Then pick an arbitrary location from "Here are the locations available
> in the category. Please select one."
>
> 4. Press "Next Step"

That's a good walkthrough, thank you.

Looking at that confirms my suspicion that the times need to be reworked
to use a standard time format: "4:17p" is unclear to a sighted user, let
alone a program like a screen reader. p.m. is the correct abbreviation,
the 12-hour clock traditionally uses a full stop not a colon, and there
should be a space between the time and a.m./p.m.

> I am retrofitting the trip planner on the Translink site.

That sounds harder than rewriting it. How much freedom do you have to
redesign and rewrite the frontend HTML/CSS/JS of the journey planner
from scratch? It could definitely use it. Some usability and
accessibility problems I noticed with that Results page alone include
(in no particular order):

1. There's a link to check another page for service announcements that
might affect your trip (and your choice of journeys). The Transport for
London journey planner tells you which journey options are affected by
current service announcements with handy messages like "Problems are
currently reported on this route" and "Planned engineering works are
taking place" on the results page.
2. Failure to set initial focus with a fragment identifier, forcing
users to skip through the same initial set of links.
3. Mixture of table layouts with data tables will make it harder for
assistive technology to distinguish the two. Failure to use data table
markup, like the TH element, for said data tables will make it even
harder still.
4. Many images have no alt attributes, and this is exacerbated by the
use of </img> closing tags which are illegal in HTML and may be
error-corrected to create a second image element. In many cases, alt
text would be needed to provide link text or table column headings.
5. Use of images for text, inhibiting resizing or recoloring or changing
the font to suit the user's preferences.
6. Distracting (constantly changing), irrelevant ("Join our online
advisory panel"), confusing ("Click here") Flash animation at top right
that needs replacing with a simple link at the bottom of the page somewhere.
7. The route summaries are poor. There needs to be some indication that
the numbers in the first column are bus numbers. Expo Line is not an
acronym; 999 is not its expansion; neither is going to be particularly
comprehensible to those who are from out of town, but Expo Line (999)
might be an improvement for those who aren't.
8. Using a term and then explaining on the some page that you don't
really mean it, and on another page that it doesn't have the
implications one would expect, is very confusing, but that's what is
being done here with the word "transfers". I recommend finding a term to
distinguish transfers "where you stay on the same vehicle" from
transfers where you don't. The Help system says "This means that during
the course of your trip, one bus route turns into another bus route with
little if any time between." This is surely a critical distinction when
picking a journey option since people basically avoid "transfers" to
avoid the journey being slowed or disrupted.
9. If a design requires labeled arrows pointing to the controls you're
meant to click, then it's not clear enough to begin with. There are no
hover or focus styles or effects for the all-important "Detail" buttons,
which look too much like the table headings and not enough like links or
buttons.
10. Poor contrast between blue text and blue backgrounds.
11. No ability to reorder the results by different criteria (e.g. by
number of transfers rather than duration).

Hope that helps.
--
Benjamin Hawkes-Lewis