This Wiki page is edited by participants of the HTML Accessibility Task Force. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Task Force participants, WAI, or W3C. It may also have some very useful information.

Talk:Verbose desc reqs

From HTML accessibility task force Wiki
Revision as of 14:21, 26 April 2011 by Bhawkesl (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Verbose Descriptor Requirements Feedback

Feedback from Jan Richards (2010)

source: Feedback on verbose descriptor requirements (post to w3c-wai-ua, 2010-09-09)

  1. Format requirement: A programmatic mechanism to reference a specific set of structured content (e.g., text, table, etc.) as a verbose descriptor to non-text content.
  2. Format requirement: The verbose descriptor should be able to be stored internal (enhanced describedby model) or external (HTML4 longdesc model) to the document containing the described non-text content.
  3. Format requirement: The mechanism should clearly define the start and end of the verbose description in case it is part of a larger document.
  4. UA requirement: User option to indicate programmatically (e.g. via an AT) that a piece of non-text content has a verbose descriptor.
  5. UA requirement: User option to indicate in the viewport (e.g. visually in a standard browser, aurally in an aural browser) that a piece of non-text content has a verbose descriptor.
  6. UA requirement: Verbose descriptor must be available programmatically (e.g., via accessibility API to AT).
  7. UA requirement: User option to display verbose descriptor and non-text content together (e.g., in the same viewport).
  8. UA requirement: User option to display verbose descriptor separately (e.g., open in a new viewport).
  9. UA requirement: User must be able to return easily from the verbose description (whether internal, external, etc.) to the described non-text content.



Feedback from Rich Schwerdtfeger (2011-04)

1. A programmatic mechanism to reference a specific set of structured content structured host language content, either internal or external to the document containing the described image.

RS comment: Change structured content to structured host language content. We don't want to use PDF to describe HTML or vice versa

GJR comment: this change has been effected to the requirements document


2. A way to inform users and authors that a description is present/available.

RS comment: This is a change to longdesc in that it provides additional functionality. This can be achieved by a plug-in for example. If they are trying to delete longdesc this may be a hard sell. This may best be addressed by user agent requirements for ARIA if we can get the browser vendors to agree. At least it could be consistent across browsers. Is this a UAAG requirement?


3. A device independent way to access the descriptive content.

RS comment: This is a change to longdesc in that it provides additional functionality. This can be achieved by a plug-in for example or by web applications themselves. If they are trying to delete longdesc this may be a hard sell. This may best be addressed by user agent requirements for ARIA if we can get the browser vendors to agree. At least it could be consistent across browsers. Is this a UAAG requirement?


4. An explicit provision that accessing descriptive content, whether internal or external to the document containing the image, does NOT take the user away from the user's position in the document containing the image where the verbose descriptor was invoked;

RS comment: For a blind user to read the long description you will temporarily need to take the user away from the position. Note: this is another reason to not limit ourselves to native host language properties as part of the strategy. We might instead focus on a single way to do short (labels) and long descriptions consistently across elements such as through the use of ARIA properties

I suggest some rewording, something like: An explicit provision that accessing descriptive content, whether internal or external to the document containing the image, does NOT take the user away from the user's position in the document containing the image where the verbose descriptor was invoked when the AT has completed reading the description and wishes to quickly return back to the element to which the description is applied.


5. A way to provide user control over exposition of the descriptor so that rendering of the image and its description is not an either/or proposition. (A visual indicator of the description should NOT be a forced visual encumbrance on sighted users by default).

RS comment: this is an additional requirement for a property that they are trying to remove.


6. A method to reference a longer description of an image, without including the content in the main flow of a page.

RS comment: this is an additional requirement for a property that they are trying to remove.


7. Since an img element may be within the content of an a element, the user agent's mechanism in the user interface for accessing the verbose descriptor resource of the former must be different than the mechanism for accessing the href resource of the latter.


8. A means of accessing content added by authors using the HTML4 attribute longdesc (backwards-compatibility for "legacy" content) <ins>should it get removed.


9. Ease of use.

RS comment: What aspect is ease of use? It would appear you addressed ease of use above.

GJR comment: the "ease of use" requirement was not one of the original 7 requirements -- it was added by a third party, and whilst i believe that "ease of use" is covered by the other requirements, i have been loathe to remove "ease of use" until the TF decides whether or not "ease of use" has been successfully addressed by the other, specific, requirements.


10. Should longdesc be targeted for removal, HTML must deprecate the attribute with an acceptable time frame to allow for industry to produce an accepted alternative.

More observations from Rich:

Should we use ARIA as the replacement strategy long term we must be clear that ARIA implementations (post 1.0) must require that user agents support these interactive features. This could be a user agent conformance behavior for UAAG or the host language.

Feedback on "Requirements" section from Benjamin Hawkes-Lewis (26 April 2011)

Requirement 1 states "A programmatic mechanism to reference a specific set of structured host language content, either internal or external to the document containing the described image." I see no reason to treat referencing an external resource as an accessibility requirement.

Requirement 4 states "An explicit provision that accessing descriptive content, whether internal or external to the document containing the image, does NOT take the user away from the user's position in the document containing the image where the verbose descriptor was invoked." I think this is supposed to mean that after consuming the long description, the user should be able to easily continue consuming the main document from where they left off. If so, it could be more clearly stated.

Requirement 9 states "Ease of use". I'd have thought this would go without saying, much like security.

In general, I don't think these requirements should be translated into MUST or SHOULD UI requirements in conforming UAs, but rather into suggested UI, as I think the markup spec should be dictating semantics not UI.