full text of the comment:

[[
Attached and below, please find the VHA Section 508 Office comments
pertaining to various sections of the current HTML5 specification.  They
have been listed by section name in a single document.  Many of these
comments regard concerns about the impact of the current specification
on accessibility for people with disabilities.  As a government agency
who serves persons with disabilities while trying to use the latest
online technologies, we believe it is vital that accessibility be
supported and encouraged as new technologies and protocols emerge.
Thank you for your consideration of these comments.

 

The Title Element

Since the title attribute can be applied to almost any element, reliable
means will need to be provided to allow AT users and those who do not
use a mouse, to be able to access that advisory information without
being hampered by it.  Not having access to tooltips is occasionally
problematic now, but not being able to access information such as source
reference information for a paragraph when located in a title attribute
on an element that cannot gain keyboard focus will be even more of an
issue.  

Also, here "description of an image" is listed as advisory information,
continuing the confusion about where "alt" is appropriate and where
"title" should be used.  The description of an image is not "advisory"
it is descriptive.  The description of the purpose of an image might be
advisory.

For instance the image of a printer being used to send to a printer,
should have alt="print" or alt="printer" but title="Click this button to
send to a printer".

 

DL/DT/DD

The definitions of these elements seem too vague and it appears to be
implied that they are really for use in placement of certain kinds of
text lines in relation to each other.  On their own, without the dfn
element, they are no longer explicitly meant to be used for
"definitions" as such. Since these elements were being used for other
purposes anyway, that seems understandable, however, aside from the
admonition that they are not for use for dialog, no strong case is made
for why they should be used as demonstrated, especially where other
semantic or stylistic elements could serve.  They appear to be meant to
show relationship within a group, but it also appears that that
relationship can be entirely arbitrary.

 

A phrase or paragraph with an alternative graphical representation:
charts, diagrams, graphs, maps, illustrations

This section is clearly meant to fill the role of the longdesc
attribute.  Unfortunately, the reasoning used is flawed.  It assumes
several things:

1. That all users require the same level of description for complex
information at all times;

2. That the alt attribute is adequate to the task of conveying textual
descriptions of graphical information.

At the VHA, we encounter graphical information in the form of
screen-captures of what would otherwise be tabular data, or charts with
complex interrelationships of information.  If the suggested
implementation here were to be used, a user (such as a screen reader
user) could encounter something like: 

<img src="screenshot.jpg" alt="Table with five rows and five columns
listing types of conditions and their severity. The first cell (column
1, row 1) is empty. Column 2, Row 1, says Pulmonary; Column 3, Row 1
says Circulatory; Column 4, Row 1 says Muscular; Column 5, Row 1 says
Neurological. Column 1, Row 2 says, Minor Concerns ... Column 5, Row 5
says coma"> 

Not only would this be tedious to listen to for anyone who just needed
to know that the image was a screenshot with lists of different types of
ailments, it would not allow them to explore the layout of the table in
a 2-dimensional way, to understand the relationship of the tabular data.

The argument could be made that this information should have been
provided in tabular form anyway, without the graphic, except that the
purpose of the graphic is not just to convey the data itself, but to
show how it would be presented in a particular computer application for
a user to select from.

It would be much more useful to provide multi-layered description (such
as could be available with a modified and updated longdesc attribute) so
that the image would be presented as:

<img src="screenshot.jpg" alt="screenshot of ailment selection screen"
longdesc="LinkToTableInformationForThoseWhoWantIt">.  

This would also be true of complex charts describing multiple factors
that interact, or in less formal items like clothing catalogs where both
an alt="short-sleeved shirt" could be supplemented with a
long-description that gives details to only those who need more
description.  Those who were not looking for ANY type of short-sleeved
shirt would not have to deal with the description of the fabric and
color, etc.

However, if a new form of long description is implemented, the
description of how to utilize it should be made much clearer, and
user-agents should be able to make that information available to any
user who wants it; not just screen-reader users.  In some ways, it would
seem that adapting the details element to this purpose could work nicely
(perhaps also becoming an attribute of img, or there should be a way of
adapting it to an "additional information about images" role).  Coming
up with a details-as-attribute or being able to apply a details element
to an image could alleviate one of the problems with longdesc - far too
few people knew what it was meant for.  Since the details element is
described as being something that is used to provide further information
on text, being able to apply it or something like it to img would
basically do the same thing - provide a clickable element that indicates
that there is more information available.

 

Guidance for conformance checkers

Allowing a conformance checker to allow images without alt attributes as
long as they have a title attribute are asking for trouble.  Already,
people assume that title and alt can serve the same purpose, and
although the spec explains the limited situations in which a title
attribute is acceptable, your average web-developer is not going to read
the specification.  We have not gotten web devs to reliably implement
alt attributes yet, allowing conformance checkers to pass an alt-free
img because it has a title attribute, or because the image has been
generated with certain tools, will only maintain the level of "but the
checker said it was fine" that we already have.  Images without alt
attributes should always be flagged. If exceptions need to be made for
the cases listed in the situations cited, those exceptions should be
made knowingly by a human being somewhere (webmaster, site maintainer,
etc.).  Also, with the advancing level of image recognition, there may
eventually be automatic ways of generating rudimentary alternative text
which could also count as rudimentary keyword generation for
categorizing online images.  Explicitly excusing a condition based on
current inconvenience and limitations seems short-sighted.

It would also be useful to have a way to view alternative text even if
images are not turned off, for users who would benefit from this
feature.

PS. The suggested alternative text for the image taken by the blind
photographer would seem to be inaccurate.  Hummingbird feeders do not
contain nuts and seeds, they contain sugar water, so whomever described
the picture as a hummingbird feeder has mislead the alt-text reader.

 

The Video Element

There does not appear to be any provision for providing alternative text
for the Posterframe of the video.  I understand why this would be
something that is difficult to require, but it should be possible, and
even recommended.  After all, there might be a video whose title is "A
Day At The Beach".  Knowing whether the posterframe contains the image
of a child throwing a ball into the surf for their dog, a surfer heading
into the waves, or an attractive couple holding hands, conveys very
different information about what that video might contain.

 

The Audio Element

No provision appears to be made for simple visual alternatives to
indicate that audio is playing to let a deaf user know.  This is not the
same as a caption or a transcript, but would be the ability to provide a
quick indicator of important sound effects, or even just to let the user
know that there is a piece of music looping in the background.  Without
a way to provide this kind of information, users with hearing impairment
could miss vital audio cues, or could inadvertently annoy people nearby
because the machine they are using has its speakers blaring a midi loop
of "Mary Had A Little Lamb". 

 

The Canvas Element

Other than a reference to providing keyboard accessibility in the
fallback content, there is no reference to providing accessibility for
users with various disabilities.  Visual focus for off-screen elements
is an issue for users of screen magnification and low vision users, with
no visual keyboard indication and no tracking of programmatic focus in
the magnified area.  This makes "fallback content" appear to be the
"text-only alternative" of this decade.  Until there are strong
recommendations for how to make Canvas content accessible, there is a
huge risk of unequal access to interesting and innovative content.

 

The Area Element

It states that if an area does not have an href then it cannot be
selected and thus does not require an alt attribute.  It is unclear how
that would comply with other requirements for alternative text on
images.  For example, imagine the areas in an image map represent rooms
in a house, but only the kitchen, living room and bedroom can be
selected, but there are also a bathroom, a dining room, and a library
represented in the image, which are not presently active.  Not providing
text representations of those rooms would be withholding information
from a user who does not have access to the image.  This would be
especially true if links from areas are dynamically generated.  It would
seem that having an area's text representation appear and disappear,
could be more disconcerting than having it always present, but with
appropriate indicators of whether it is an active link or an inactive
graphic.  Inactive areas could be kept out of the tab order though.
Also, a means would have to be provided for areas with empty alt
attributes from being placed in the tab order.  

 

Input Elements

Extensive work will need to be done that the new elements have
appropriate accessibility for users with disabilities, including
keyboard/non-pointer-device accessibility, as well as appropriate
indicators of states and attributes that impact how or whether a user
can interact with that input element.  Although there could be great
promise in having a consistent means of providing input elements,
accessibility concerns will need to be taken into account when
determining how user agents display that information to the user, and
expose information to AT.

 

The Required Attribute

The availability of this attribute could vastly improve the consistent
accessibility of this information to users with disabilities.  However,
for this to be true, work will need to be done to assure that user
agents provide means to indicate the required state to all users,
including those with disabilities, regardless of whether they are using
AT.  Displaying consistent visual cues (that are (or can be made)
non-color-dependent), as well as programmatic indication for AT will be
necessary.  

 

The Menu Element

Although there is great potential usefulness in the menu element, a lot
of careful work will need to be done to assure that the variety of
children, options, list items, command elements, etc., it can support
are consistently accessible to users with disabilities across all
available browsers.

 

Element level Focus APIs

In this section, people are instructed to use CSS to hide the focus ring
if they "find it unsightly".  There should be additional information
letting them know that doing so can jeopardize accessibility for some
people including those who can see the screen, but who also rely upon
keyboard accessibility.  

 

Content Editable 

There is insufficient discussion of keyboard accessibility for this
feature.  More needs to be provided beyond caret position and selection
information.  This is also true for Document.designMode.
]]

mass-moved component to LC1

Could someone split this into one issue per bug?

split into bug 13725, bug 13726, bug 13727, bug 13728, bug 13729, bug 13731, bug 13732, bug 13733, bug 13734, bug 13736, bug 13737, bug 13738, bug 13739

Mia, I suggest that you add yourself to the CC list for each of those bugs. I will be closing this bug out.

(Also, I notice that several of the comments are not specific requests for changes to the spec but instead general comments along the lines of, e.g., "work will need to be done" or "research will need to be done". We don't normally raise spec bugs for general comments like that, but instead only for comments that are actionable by an editor. I went ahead and filed them in this case just for the sake of completeness.)

*** This bug has been marked as a duplicate of bug 13739 ***

Closed on behalf of bug triage.