- 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>
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: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13737#c1 "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". > > > > 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. > > > > > > > > Mia Lipner > > Section 508 Program and Management Analyst > > 415.400.4122 > > > -- Michael[tm] Smith http://people.w3.org/mike/+
Received on Monday, 21 November 2011 22:25:14 UTC