[Webkit-unassigned] [Bug 25524] [Gtk] Expose the title attribute to assistive technologies

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=25524





--- Comment #17 from Joanmarie Diggs <joanmarie.diggs at gmail.com>  2009-07-23 06:01:12 PDT ---
Consider the following:

  <form>
  Phone: <input type="text" title="Enter your number without dashes." />
  </form>

I see stuff like this all of the time. The assumptions made by the content
provider presumably are:

1. The user can see (and thus knows "Phone:" is the functional label for the
field).

2. The user uses a mouse and will therefore see the the helpful title
information as they hover the mouse over the field they are about to fill out.

What a screen reader user wants to hear and/or see in braille is something to
the effect of:

  "Phone: text"

Depending on the user, he/she might also want to hear/see: "Enter your number
without dashes." (Which is why we need this information exposed.)

Unfortunately, the hypothetical content provider didn't take the time to
surround 'Phone:' in <label></label>. So even if bug 25530 were fixed, this
text field would have no name.  What a screen reader can do (and what Orca
does, and what I believe some of the Windows screen readers do) in this case is
attempt to "guess" what the functional label is. For the example above, Orca
would guess "Phone:" and present "Phone: text" to the user. So far so good.

Now enter this standard and what I believe you are proposing:

  1. The form field has no name.

  2. The form field has a title.

  3. Ergo, make the accessible name: "Enter your number without dashes."

When a screen reader -- at least Orca -- comes across a form field that has an
accessible name, it doesn't try to figure out where that name came from. Nor
does it attempt to guess a name/label for a named/labeled field. It assumes the
name is valid and presents it. As a result, when a user who is blind Tabs into
the above field, what he/she will be presented with is:

  "Enter your number without dashes. text"

Now the user must try to work out what number should be entered without dashes.
Phone number is likely, but it might be social security number, or ID number,
or order number, or subscriber number depending on the form being filled out.
In order to figure out what information is expected, the user must now look
around (non-visually) for the functional label. In other words, in an effort to
make things more accessible, falling back on the title text makes them less
accessible. :-( 

If, instead, the title attribute were exposed as the accessible description, a
screen reader like Orca could guess the functional label and present the title
information to the user upon request and/or based upon a user-configurable
option.

As for images: I feel less strongly about falling back on the title for the
accessible name. That said.... If the alt info (if any) is always exposed as
the accessible name and the title info (if any) is always exposed as the
accessible description, it is quite easy for a screen reader to:

1. Present whatever information happens to be present for the image (i.e. look
first to the name and failing that, the description).

2. Implement a setting so that users could opt to hear images with alt text,
but skip over images that lack alt text -- even if they have title text.

3. Present detailed "where am I?" information that presents the alt text (or
the absence of alt text) and the title text (or the absence of title text) to
the user and by doing so helps the user better understand exactly what is on
the screen.

In other words, the screen reader is perfectly capable of doing the "fall back
to the title as the name" thing. And if you leave it up to the screen reader to
do the fallback rather than doing it yourself, the screen reader is able to
provide a more consistent experience, customizable to best suit whatever the
needs of the user happen to be.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.