Random notes re: Web Forms: Usability and Accessibility Question.

Late to the party, but still...

Tina Holmboe wrote:

> Second, how is that "*" supposed to be read ? A screen reader cannot
> automatically interpret it and read "Mandatory field", even if it
> exist in a LABEL - nor are there any one way of reading the character.
>
> Splat ? Asterix ? Star ? How should the "*" be read in an English
> document ? Granted, the speech browser should read the text in
> English, but what about the splat ?

It should also be remembered that most popular screen reading technologies
allow the end user to set the verbosity settings in their readers.  I know
that in JAWS you can set it to read "No Punctuation", "Some Punctuation",
and "All Punctuation".  I believe that a similar setting exists in
WindowEyes as well.  This means that some users would possibly not hear the
Splat/Asterix/Star, let alone understand that it is an indicator for
"mandatory"...

>
> Consider, also, the speed with which many speech systems operate. I
> have had the dubious pleasure of hearing the old Greytower site read
> by Jaws - I couldn't keep up, and I'd written the text it read.

Again, another setting in the screen reading tool(s).  Most users of the
tools become quite adept in understanding the voice, and are able to follow
at an accelerated speed that leaves those with little or no experience
bewildered (as Tina has indicated).  One item to note here is that, because
of this "speed reading" capability, mis-spelled words and/or acronyms can
cause comprehension issues.

<.strong>For this reason, a simple spell check on your content is
crucial!!!<./strong>

As well, using the <.acronym> or <.abbr> elements should be always
considered.  Just this week, in reviewing a document, we encountered the
acronym "TTY"; the screen reader spoke "Tie" - but as well, I was unable to
explain what the acronym actually stood for, although I knew it to be an
Assistive system for some disabled users.

Currently I would recommend *ONLY* the <.acronym> element (semantic debates
aside), as the browser most commonly used with the screen reading
software(s) is Internet Explorer, which does not currently support the
<.abbr> element.  (Before anybody chimes in, yes, I know that the W3C is now
advancing <.abbr> and deprecating <.acronym>; somebody want to remind
Redmond?)


Then, Patrick H. Lauke wrote:

> To play devil's advocate: shouldn't they be using a screen magnifier or
> something like Opera's page zoom, which scales both text and graphics ?


To which, Tina replied:

> Well, my question then becomes: "Why should they?"
>
> I can readily imagine, say, an older person with somewhat reduced
> eyesight - going to happen to most of us - who doesn't really feel the
> need for a specialized magnification tool, but feel quite comfortable
> with increasing the font size in his/her UA.
>
> Tiny symbols that may or may not carry meaning and implemented as
> graphical elements -is- a problem for that specific group; both as
> links and as information carrying elements.


We had explored this issue some time back at WATS.ca, and have a proposed
recommendation for contextually important images, icons, etc.  We cover it
in detail at: http://wats.ca/resources/relativesizing/20 - Relative Sizing
and Images, but in a nutshell - use "ems" to size your important graphics -
they'll scale with the text when enlarged via the browser settings, relative
to the font size.  Note, this may "conflict" with pixel perfect designers
out there, but that debate is for another time... <grin>

JF
--
John Foliot  foliot@wats.ca
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca   1.866.932.4878 (North America)

Received on Wednesday, 4 February 2004 18:58:00 UTC