W3C home > Mailing lists > Public > public-html-comments@w3.org > November 2011

Re: VHA Comments on HTML5 Draft Specification

From: Michael[tm] Smith <mike@w3.org>
Date: Tue, 22 Nov 2011 07:24:59 +0900
To: "Lipner, Mia" <Mia.Lipner@va.gov>
Cc: public-html-comments@w3.org, vha508admin@bayfirst.com, "Crowe, Ellen (OIFO)" <Ellen.McMahon2@va.gov>
Message-ID: <20111121222457.GB472@sideshowbarker>
Hello Mia,

Note that there has been a response to your comment about the menu element
that you or others familiar with the content of the comment should reply to:


"Lipner, Mia" <Mia.Lipner@va.gov>, 2011-08-02 15:18 -0500:

> Hello,
> 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".
> 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.  
> Mia Lipner
> Section 508 Program and Management Analyst
> 415.400.4122

Michael[tm] Smith
Received on Monday, 21 November 2011 22:25:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:28 UTC