Skip to content

Considerations for the Accessibility review

Jump to bottom
Nigel Megitt edited this page Jul 18, 2023 · 6 revisions

Tasks:

FAST checklist

  • If technology allows visual rendering of content
    • There is a defined way for a non-visual rendering to be created.
    • Content can be resized.
    • Luminosity and hue contrast can adapt to user requirements.
    • Text presentation attributes can be changed.
    • Visual presentation of pointers and cursors can be adjusted.
    • Changing content presentation does not render it unreadable.
    • Technology does not allow blinking or flashing of content, or provides a feature for users to quickly turn it off or permanently disable it.
    • It is possible to make navigation order correspond to the visual presentation.
  • If technology provides author control over color
    • There is a mechanism for users to override colors of text and user interface components.
    • There is a feature for authors to define semantically available "color classes" that users can easily map to custom colors, and give preference to this vs. coloring objects individually.
    • There is a feature for users to choose color schemata that work for them.
    • The foreground and background color of an object can be reported to the user via AT.
    • There are ways to set foreground and background colors separately for all objects.
    • Compositing rules for foreground and background colors are well defined.
No user input features are specified.
  • If technology provides features to accept user input
    • There is a mechanism to label user input controls in an unambiguous and clear manner.
    • Authors can associate extended help information with a control.
    • If there is an input error, it is possible to associate the error message clearly with the specific control that is in error.
    • There is a mechanism to report and set the state or value of controls programmatically.
    • Authors can address multiple types of input hardware (keyboard, pointing device, touch screen, voice recognition, etc.), or the technology supports hardware-agnostic input methods.
    • User input does not require specific physical characteristics (e.g., fingerprint readers).
    • Authors can ensure a "meaningful" order of controls exists regardless of presentation.
No user interaction features are specified.
  • If technology provides user interaction features
    • For every user interface object type, the "type" of object can be exposed as a role to accessibility APIs.
    • For every user interface object type, there is a clearly defined mechanism for authors to provide and / or user agents determines the "accessible name" for accessibility APIs.
    • For user interface objects that can have states, properties, or values, authors can set these and these can be exposed to accessibility APIs.
    • When providing imperative mechanisms to implement technology features (e.g., scripts), authors can expose accessibility information to accessibility APIs.
    • User can obtain help information about the widget.
  • If technology defines document semantics
    • Authors can title Web pages.
    • Authors can title sections of content.
    • Authors can clearly indicate the target of a hyperlink and function of a control.
    • Authors can indicate content language, for the page as a whole and for blocks of content.
    • Authors can support understanding of abbreviations / acronyms / initialisms, idioms, jargon, etc.
    • Authors can support correct machine pronunciation of ambiguously spelled terms (e.g., in the phrase "I am content with this content" there are different correct pronunciations of the lexeme "content"). This is something we plan to add in future.
    • Authors can identify regions of content, particularly the "main" region.
    • Declarative mechanisms (that have accessibility semantics pre-defined in the spec) are used to implement technology features whenever possible. We don't define accessibility semantics explicitly
    • There are unambiguous ways to express relationships between units of content, such as object nesting, ID referencing, etc.
    • Prefer structural semantics to presentational semantics.
    • When providing presentational semantics, they can be easily mapped to structural semantics, e.g., to support restyling or meaningful exposure to accessibility APIs.
    • Support a comprehensive set of authoring use cases to minimize the need for alternative content. (e.g., don't make authors resort to text in images to get the style they want).
    • Semantics allow precise and replicable location information in the document to be determined.
    • Semantics exist to convey meaning that is commonly conveyed via presentation. Few things like headings are relevant here
  • If technology provides time-based visual media (see also the Media Accessibility Checklist)
    • It is possible for authors to provide detailed text descriptions, audio descriptions, or both of the important content in the media.
    • It is possible for authors to synchronize descriptions with the visual content.
    • It is possible for to provide descriptions even when the content is live. No support for live is intended
    • User can pause, stop, replay media. Out of scope
    • Users can send output to alternate device.
  • If technology provides audio
    • It is possible for authors to provide transcriptions.
    • It is possible for authors to provide synchronized captions, either open (on by default for all users).
    • User can adjust volume level Arguably out of scope but semantics of mixing instructions can be overridden
    • Contrast between foreground and background audio is sufficient Technology allows this - it depends on the document author
    • Unnecessary background audio can be muted separately from the foreground audio
    • Technology does not include triggers for audiosensitive seizures or allows those triggers to be disabled. Not enough information to assess this
  • If technology allows time limits The time limits are not limits on the user - if extended descriptions are needed they can be implemented in players - we have not identified any additional signalling needed in DAPT for this.
    • A feature exists to allow time limits to be extended.
    • Time limits for different parts of a task, such as reading instructions vs providing input, can be set separately.
  • If technology allows text content
    • Authors can define non-text alternatives for text content.
    • Authors can define non-text alternatives for non-text content. Not relevant directly, but users can use AT to render audio as Braille, for example, via the text alternative to the audio
By definition all of the objects have an inherent text representation.
  • If technology creates objects that don't have an inherent text representation
    • There is a mechanism to create short text alternatives that label the object.
    • There is a mechanism to create extended text alternatives for fallback content.
    • Text alternatives can be semantically "rich" e.g., with page structure, text style, hyperlinks, etc.
No content fallback mechanisms are provided.
  • If technology provides content fallback mechanisms, whether text or other formats
    • Authors can explicitly mark content as not needing alternative content because it does not perform an important role.
    • Content can explicitly indicate when author declined to provide alternative content.
    • Content can explicitly indicate that authoring tool is unable to generate or obtain alternative content.
    • Authors can explicitly associate alternative content with the primary content.
    • Authors can associate multiple types and instances of alternative content with primary content.
    • Alternate content can be easily found from the initial content.
  • If technology provides visual graphics
    • Item
  • If technology provides internationalization support
    • Accessibility features can be internationalized to the same degree as other features
  • If technology defines accessible alternative features
    • Accessible alternatives themselves meet the same bar of accessibility.
  • If technology provides content directly for end-users
    • Content can be encoded in a manner that allows machine transformation into accessible output
No API or transmission protocol is defined.
  • If technology defines an API
    • If the API can be used for structured content, it provides features to represent all aspects of the content including hidden accessibility features.
    • If the API relies on user agents to generate a user interface, the specification provides guidance about accessibility requirements needed to enable full interaction with the API.
  • If technology defines a transmission protocol
    • Use of the protocol does not cause any aspect of the content, including metadata which could contain important accessibility information, to be removed.
    • It is possible to use third-party accessibility enhancement services while using the protocol.

Textual description and explanations of the accessibility considerations

DAPT defines a document format for exchange and distribution of accessible or localised alternatives, for use with video media.

The expected working model is that authoring tools will present the contents of a DAPT document, visually, primarily as text, but that those contents will be provided to end users, i.e. consumers of the video media, either as an alternative or modified audio experience, or as a text alternative to the media. That text alternative is not expected to be styled for presentation but can be used as the basis for creating accessible subtitles or captions, for example, in a different format such as IMSC Text Profile.

This latter usage in particular can increase accessibility by addressing a common industry problem when dubbed audio does not closely match the (translated, used as an aid to the hard of hearing) subtitles, which imposes a significant additional cognitive load on the viewer. We envisage that content providers can commission a single translation into each target language and use it as a common basis for both dubbing and subtitles, so that there is less linguistic difference between them, and that cognitive load is reduced.

The visual presentation is mainly a concern of authoring tool implementers. It is possible to store styling decisions within the DAPT document using TTML styling, but this is not a requirement; nor is it a requirement for interoperability that DAPT tools honour such styling information. Therefore we consider the accessibility of the visual presentation of script contents to be largely out of scope of the DAPT specification. On the other hand, if DAPT scripts are used as the basis for generating subtitles, then at that point the visual presentation requirements of the subtitle format would apply.

DAPT defines document semantics, but those are not semantics of web pages specifically. Therefore questions such as "Authors can title Web pages" are not relevant. However it is a strong requirement of DAPT that all text content is labelled for language, and that structural semantics are clearly defined.

DAPT defines a mechanism to provide time-based media with accessible alternatives, synchronized with the media. This is a key part of the intent of the specification, to enable content providers to generate those accessible alternatives using tools that interoperate with an open standard exchange format.

For audio descriptions, where the "technology provides audio", DAPT allows the author to provide mixing instructions that adjust the relative volume level of the audio description compared to the main programme audio; some implementations will pre-mix the audio descriptions into the programme audio, in which case no local adjustment by the user will be possible; however in clients that play back DAPT directly, it is possible for them to adjust the levels set in the mark-up to suit the user's choice. This is out of scope of the specification, however.

We have considered extended descriptions, but have not identified any additional signalling needed in DAPT to support them. Rather, if the component mixing the audio description into the programme audio identifies that an audio resource is longer than the time allotted to play it back, we would expect some implementation-dependent behaviour to be defined, for example to speed up playback of the description, or pause programme playback until the description is completed. Default behaviour as specified is to truncate playback of the audio resource in this situation.

Clone this wiki locally