Substantial Conformance/Example Scenarios

From Silver

Summary

The purpose of this document is to outline situations in which ensuring conformance of websites and applications might present a challenge for content providers, despite best intentions and efforts. The intent of this document is to help form a shared understanding of such situations, to contribute to the development of accessibility resources. These resources could include:

Problem Description

Content providers encounter situations where trying to make content conform to accessibility requirements might present challenges for them, despite best intentions and efforts. For example, when they are publishing large volumes of content, managing third-party content, and when they are adopting new technologies such as natural language interfaces and immersive environments. They then need to decide if they need to pull or not publish the content, versus seek more pragmatic approaches to address the situations. WCAG 3 and other resources from WAI, such as Planning and Managing Web Accessibility, have the goal to support content providers in such situations. However, we lack a shared understanding and common description of these situations across the different WAI groups. This makes some discussions less effective. Moreover, not all challenges can be resolved alone through technical standards and resources from WAI. Some challenges need to be addressed through accessibility policies that are not developed by WAI. For example, most accessibility policies, such as the Americans with Disabilities Act (ADA) and European Accessibility Act (EAA), include concepts around reasonable accommodation and undue burden. That is, we need to understand the context around the situations. Some of them are more technical in nature, and others are more policy related. Understanding this helps us approach the parts that fall within the scope of WAI.

Approach and Structure

This document provides a collection of situations where trying to make content accessible might present challenges for content providers. The intent is to identify common patterns across the different situations, and help form a shared understanding for them. This could contribute to the development of accessibility resources from WAI. This includes informing the development of the conformance model and provisions in WCAG 3. Another potential outcome could be WAI guidance with considerations for policy makers wanting to adopt WCAG.

Each situation in this document is illustrated with one or more brief example scenario. Each situation also includes a high-level outline of:

  • How technical standards might contribute to addressing the situation
  • How accompanying guidance might contribute to addressing the situation
  • How accessibility policies might contribute to addressing the situation

The situations and examples cover a broad range of sectors, including public, commercial, education, and more. However, they are not in any way exhaustive. The situations are also not mutually exclusive - multiple situations could be applicable to the same content at the same time.

The situations and examples are not intended to cover the all too frequent instances where content providers fail to consider accessibility requirements, whether out of ignorance or negligence. These are real concerns that need to be addressed. They are simply outside the scope of this particular document. In this document we intentionally presume that content providers are doing their best to consider accessibility to the extent they reasonably can.

Key Terminology and Concepts

Some of the key terms and concepts used in this document include the following:

  • Content Provider: person or entity providing content to others, for example through a website, mobile app, and other user interfaces.
  • Content Creator: person or entity creating the content. This includes content in different formats, such as text, code, audio, and video.
  • Content Owner: person or entity owning the content. This can be the commissioner of the content or another holder of the rights.
  • Conformance: adhering to technical standards. In this context accessibility standards, such as the W3C Accessibility Guidelines (WCAG).
  • Compliance: adhering to laws and other types of policies. In this context accessibility policies, such as the European Accessibility Act (EAA).
  • Relative priority for people with disabilities: in the context of this document refers to prioritizing certain content before other content, not to exclude any content as irrelevant for people with disabilities. For example, a restaurant owner might prioritize improving accessibility of the information on accessibility of the restaurant before improving accessibility of the picture gallery.
  • Reasonable efforts concepts: refers to concepts such as "reasonable accommodation" and "undue burden" that exist in many policies, such as Americans with Disabilities Act (ADA) and European Accessibility Act (EAA).

Note: This is not intended to be any glossary definition of the terms, just an introduction of these concepts in the context of this document. If accepted by the group, these terms used in the finalized documents may be considered for aligning with and adding to the corresponding glossary definitions.

Status of this Document

This document is developed by the Silver Conformance Options subgroup. It has undergone several cycles of review and continues to be worked on by that group. The document has also been presented to the parent Silver Task Force and is undergoing further review there as well.

List of Example Situations

In this section:

Situation 1: Bugs and other issues of oversight occur in content

In this situation the content provider is committed to accessibility but, despite all efforts, virtually all software has bugs and other issues of oversight.

  • Example 1.1 - website with many content authors: A news service takes accessibility very seriously. All functionality, including navigation, search, and subscribing to the news feeds conform to the technical standard. All staff who publish content are required to complete regular training on accessibility, along with the other training they receive on writing. The service provides accessibility checkers and tutorials for its staff, and runs regular scans and spot-checks for accessibility. Anyone can also report issues they find, which are quickly addressed. Despite all that, here and there conformance issues occur. The issues are filed as bugs in the central bug tracking system and are processed according to their severity level, together with other content issues.
  • Example 1.2 - application with high degree of complexity: A service provider creates a tool that allows users to create complex forms and questionnaires. It has ready-made components like checkboxes, radio buttons, drop-down menus, sliders, and other form controls that users can combine to create their own online forms. Each component conforms to the technical standard on its own as well as in combination with most other components. However, with the growing number of components and possible ways of combining them, it is no longer possible to exhaustively test every possible permutation. Despite all efforts of the service provider to avoid conflicting combinations, they do occur in some situations. This is not limited to accessibility, and also other issues can occur. When such issues are reported, they are filed as bugs and treated based on their severity level in a consistent way.

How technical standards might contribute to addressing this situation

Example provisions that technical standards could define to help address this situation include:

  • Define severity levels for accessibility requirements and issues based on their impact on people with disabilities.
  • Define where possible tolerances and quality levels for accessibility requirements, for example to distinguish between inadequate, sufficient, and good implementations of the requirements.
  • Define consistent ways for content providers to provide mechanisms for users to report accessibility issues they encounter. An example of such a mechanism might include contact information provided by the content provider in an accessibility statement.

How accompanying guidance might contribute to addressing this situation

Example guidance to help address this situation could include:

  • Provide examples to illustrate the situation and potential approaches to help address the situation (similar to the examples in this document).
  • Provide examples of good practices in writing accessibility statements (in human- and machine-readable formats).

How accessibility policies might contribute to addressing this situation

Example considerations that accessibility policies could adopt to help address this situation:

  • Define accessibility oversight and tolerance levels in content. This could include considerations for:
    • type and volume of the content in question
    • frequency in which the content is used
    • importance of the content to the core purpose of the overall online presence (website, app, ...)
    • relative priority of the content for people with disabilities
    • how accessibility bugs are addressed in relation to the impact they may have on specific groups of people
    • any systematic exclusion of accessibility versus evolving improvements
    • size and capability of the content provider
    • potential alternatives and compromise solutions
    • applicable reasonable efforts concepts
  • Define acceptable grace periods for addressing identified bugs for the different types of content, also based on the considerations listed above. For example, the acceptable periods for healthcare content may be different than for entertainment, and the acceptable levels for time-sensitive information (such as safety alerts, announcements, and such) may be different than other types of information.

Situation 2: When large volumes of content are accumulating too rapidly to make fully conforming

In this situation the continually compounding content makes it prohibitive for the content provider to ensure full conformance of the entire content.

  • Example 2.1 - content being generated by users: An online shop provides functionality for users to provide product reviews. The online shop receives thousands of reviews each day, each of which can include formatted (rich) text, images, and video content. The online shop provides help pages with information on accessibility good practice, with specific suggestions for users. The online shop is programmed in such a way that accessibility issues in the content generated by users does not interfere with the accessibility of other content. For example, audio uploaded by users cannot be set to play automatically. It also allows users to provide textual descriptions for images, and captions and audio/visual descriptions for videos that are uploaded by users. For several languages, the online shop provides captions that are automatically generated for the user to correct before publishing the reviews. Despite these measures, the shop operator cannot guarantee conformance of all the reviews it continually receives. It indicates the potential accessibility issues in an accessibility statement.
  • Example 2.2 - content being generated automatically: A weather station continually publishes satellite and radar images. This includes X images from different cameras every minute. Each image has complex visual information, including cloud formations, atmospheric pressure zones, and wind speeds at different geographic locations. The weather station provides short text alternatives with brief descriptions to identify each image it publishes, including the date, time, and name of the satellite or radar that took the image. For the few images it uses in weather forecasts, it also provides long text alternatives with more detailed descriptions of the image content (to convey the equivalent purpose of the image). These descriptions include the names of the most pertinent cloud formations, atmospheric pressure changes, and wind speeds for selected cities; it does not exhaustively describe all aspects of the images. The weather station indicates to the users which images have and do not yet have detailed descriptions, and describes the limited support for accessibility resulting from images that do not yet have detailed descriptions in an accessibility statement. It notes the rationale for this limitation, and provides a mechanism for users to request a confirming versions of past forecasts, for example for research purposes.

How technical standards might contribute to addressing this situation

Example provisions that technical standards could define to help address this situation include:

  • Define the set of accessibility requirements that can be met even under these circumstances. Examples of such requirements might include text alternatives to identify images, videos, and audio, indicating inaccessible content (for example radar images without description of the image content, and videos without audio/text descriptions), supporting users in creating accessible content (for user-generated content), and ensuring that non-conforming content does not impede on the accessibility of other content. [wording for this bullet does not yet have full consensus in the subgroup]
  • Define consistent ways for content providers to provide additional context about accessibility features and barriers in the content they provide. Examples of such context might include specifying which content does and does not yet meet the intended level of conformance, the types of accessibility issues that can occur in the non-conforming content, and the reasons for why these issues may or are known to occur. This context could be made available in human- and machine-readable formats.
  • Define consistent ways for users to contact the content provider for reasonable accommodation needs.

How accompanying guidance might contribute to addressing this situation

Example guidance to help address this situation could include:

  • Provide examples to illustrate the situation and potential approaches to help address the situation (similar to the examples in this document).
  • Provide explanations of the benefits and limitations of automated retrofitting approaches, including for language changes, text alternatives, and captions.
  • Provide examples of good practices in indicating content with and without active support for accessibility, and in writing accessibility statements (in human- and machine-readable formats).

How accessibility policies might contribute to addressing this situation

Example considerations that accessibility policies could adopt to help address this situation:

  • Define when content can be considered to be accumulating too rapidly to be made to conform. This could include considerations for:
    • type and volume of the content in question
    • frequency in which the content is used
    • importance of the content to the core purpose of the overall online presence (website, app, ...)
    • relative priority of the content for people with disabilities
    • size and capability of the content provider
    • potential alternatives and compromise solutions
    • applicable reasonable efforts concepts
  • Define criteria under which individuals can request conforming versions of the content. This could include considerations for:
    • type and volume of the content in question
    • size and capability of the content provider
    • applicable reasonable efforts concepts

Situation 3: When making large volumes of content fully conform is not achievable immediately

In this situation the content provider is committed to make specific content conform to the technical standard but has substantial challenges doing so immediately, for example for large volumes of content.

  • Example 3.1 - making content conform after acquisition: A company acquired another company with a website/app product that does not fully conform to the technical standard. The acquiring company is now training the relevant content creators, to ensure that all newly created content will conform to the technical standard. Other existing content areas will be revised to conform to the technical standard, usually with the scheduled update of the content. Some content areas will soon be phased out entirely, possibly before they can be made to conform. The acquiring company prioritizes core functionality of the website/app, to make them conform to the technical standard. For example, so that users can browse through all content areas and carry out essential functionality. The company also turned off automatic playback for all videos, also in contents areas that were not yet prioritized to make them conform, because audio from the automatically playing video disrupts use of the entire content for some users. The company indicates to the users the accessibility status of the different content areas. The company also provides an accessibility statement with details regarding the plan to revise the courses to meet the applicable accessibility requirements.
  • Example 3.2 - adapting content to changed requirements: The website and app of an organization conforms to a certain version of a technical standard, such as WCAG. A new version of that technical standard changes some of the accessibility requirements. For example, some of the requirements were modified, others removed, and yet others added to the technical standard. The organization wants to continue conforming to the technical standard but cannot update all its content and applications to conform to the new version of the technical standard immediately. For example, some of the tables and forms are generated by a content management system (CMS) that does not yet support the latest technical standard that the organization wants to meet. The organization prioritizes requirements that it can address more quickly. For example, it changes the visual design to address a new calculation for color luminosity that is introduced in the new technical standard. The organization also has a plan for addressing the remaining accessibility requirements. It indicates to the users the accessibility status of the different content areas and provides an accessibility statement with details regarding the plan to transition the content to the new technical standard.
  • Example 3.3 - making content conform requires manual intervention: A museum is digitizing and publishing a large collection of ancient scrolls for a new exhibition. The museum wants to provide text alternatives to identify each scroll (for example with the name of the artifact, owner, date, and such), as well as text alternatives for the script on each scroll. Scanning the scrolls is quicker than producing the text alternatives for the scripts on the scrolls, which requires calligraphy and ancient language specialists. Instead of withholding the scanned images until the text alternatives for the scripts on all scrolls are available, the museum publishes the images right away along with text alternatives that identify the scrolls. The museum also ensures that the content and functionality surrounding the images conforms to the technical standard. For example, so users can navigate back and forth in the gallery of images, identify the different images through clear labels, and access the different text alternatives for the images. The museum has a plan for adding further text alternatives for the scripts written on the scrolls. It indicates to the users which images have and do not yet have text alternatives for the scripts, and describes the limited support for accessibility resulting from images that do not yet have all text alternatives in an accessibility statement. It notes the rationale for this limitation, and details regarding the plan to provide the missing text alternatives.
  • Example 3.4 - making content conform requires additional processes: A training company records the trainings that it carries out, and publishes these afterwards. The training company wants to provide text alternatives that identify the videos (for example with the name of the training, trainer, date, and such), as well as captions as an alternative for the audio content and audio/text descriptions as an alternative for the visual information (such as drawings on the whiteboard, visual gestures and activities that are relevant to the training, and such). Producing the captions and audio/text descriptions requires time. Instead of withholding the videos until the captions and audio/text descriptions are ready, the training company publishes the videos right away along with text alternatives that identify each video and with automatically-generated captions. The training company also ensures that the content and functionality surrounding the videos conforms to the technical standard. For example, so users can navigate back and forth in the library of videos, identify the different videos through clear labels, and access the text alternatives, captions, and audio/text descriptions for the videos. The training company has a plan for revising the captions for better quality and for adding audio/text descriptions. It indicates to the users which videos have and do not yet have quality captions and audio/text descriptions, and describes the limited support for accessibility for some of the videos in an accessibility statement. It notes the rationale for this limitation, and details regarding the plan to provide quality captions and audio/text descriptions.

How technical standards might contribute to addressing this situation

Example provisions that technical standards could define to help address this situation include:

  • Define the set of accessibility requirements that can be met even under these circumstances. Examples of such requirements might include text alternatives to identify images, videos, and audio, indicating inaccessible content (for example images of text without text alternative, and videos without audio/text descriptions), and ensuring that inaccessible content does not impede on the accessibility of other content. [wording for this bullet does not yet have full consensus in the subgroup]
  • Define consistent ways for content providers to provide additional context about accessibility features and barriers in the content they provide. Examples of such context might include specifying which content does and does not yet meet the intended level of conformance, the types of accessibility issues that can occur in the non-conforming content, and the plan for achieving the intended level of conformance. This context could be made available in human- and machine-readable formats.
  • Define levels of conformance aggregated over entire websites and applications, consisting of more and less conforming content. For example, the previously described museum is becoming incrementally more conformant as it continues to add text alternatives for the scripts in the scrolls.

How accompanying guidance might contribute to addressing this situation

Example guidance to help address this situation could include:

  • Provide examples to illustrate the situation and potential approaches to help address the situation (similar to the examples in this document).
  • Provide explanations of the benefits and limitations of automatically-generated captions and text alternatives, and examples of good practices in using these as temporary measures.
  • Provide examples of good practices in prioritizing content in a backlog to be made conforming, for example content that has most impact or is most relevant to people with disabilities.
  • Provide examples of good practices in indicating conforming and non-conforming content, for writing accessibility statements (in human- and machine-readable formats), and in developing prioritized plans for making content conformant over time.

How accessibility policies might contribute to addressing this situation

Example considerations that accessibility policies could adopt to help address this situation:

  • Define when content needs or does not need to be made to conform immediately. This could include considerations for:
    • type and volume of the content in question
    • frequency in which the content is used
    • importance of the content to the core purpose of the overall online presence (website, app, ...)
    • relative priority of the content for people with disabilities
    • size and capability of the content provider
    • potential alternatives and temporary solutions
    • how time-sensitive the content is
    • applicable reasonable efforts concepts
  • Define acceptable timelines for ensuring conformance of the different types of content, also based on the considerations listed above. For example, the acceptable timelines for healthcare content may be different than for entertainment, and the acceptable timelines for time-sensitive information (such as safety alerts, announcements, and such) may be different than other types of information.
  • Define measures to avoid loop-holes, such as publishing inaccessible content and removing it before the end of the grace-period.

Situation 4: Content provider does not own or directly control the content

In this situation the content provider does not own or directly control the content being published by others, and cannot ensure the same level of conformance for that content.

  • Example 4.1 - website that allows users to create their own websites: A service provider creates a tool that allows others to create their own online presences. The tool itself conforms to the technical standard, and helps users to create conforming content. For example, the tool allows users to indicate headings, to provide text alternatives for images, and it generates accessible markup. The tool also provides accessibility guidance and accessibility checker tools. The provider offers additional consulting services including for privacy, security, internationalization, and accessibility. It also encourages non-professional and non-business users to implement accessibility requirements, and explains the many benefits of this including for improving search-engine optimization (SEO). In some counties, professionals and businesses are required to meet accessibility requirements, also when they use such tools. Despite all this, the tool provider cannot ensure conformance of the content created by non-business and business users of the tool because it does not own or directly control the content. (Note: this example is the opposite of example 5.3; it is about shortcomings in the content generated by an authoring tool that principally supports accessibility.)
  • Example 4.2 - portal that aggregates content from different sources: A portal aggregates different types of scientific articles from different sources. The portal itself conforms to the technical standard, and the operator contractually requires the content owners providing content through the portal to ensure their content conforms to the technical standard. The portal provides guidance on the accessibility requirements, including for images, tables, math formulas, and other types of content. It also provides accessibility checker tools, to help the content owners meet the accessibility requirements. It also runs regular scans and spot-checks for accessibility, and informs the content owners about potential issues it identifies or that get reported by users, so that they can fix them. The content owners are responsible for assessing the confirmed issues, and addressing them within a reasonable time-frame depending on their severity and complexity. They are also responsible for ensure continued conformance when they update the content published through the portal.

How technical standards might contribute to addressing this situation

Example provisions that technical standards could define to help address this situation include:

  • Define the set of accessibility requirements that can be met even under these circumstances. Examples of such requirements might include providing functionality to help content creators to create conforming content, and carrying forward accessibility features that content creators provide (for example when content is being converted from one format to another, being rendered or processed, or such). [wording for this bullet does not yet have full consensus in the subgroup]
  • Define consistent ways for content creators to provide additional context about accessibility features and barriers in the content they provide. Examples of such context might include specifying if the content indicates headings, contains text alternatives for images, and is coded in accessible markup. This context could be made available in human- and machine-readable formats.
  • Define consistent ways for content providers to provide additional context about accessibility and barriers of the content. Examples of such context might include specifying the accessibility features that are provided in content they provide, including content aggregated from different sources. This context could be made available in human- and machine-readable formats.

How accompanying guidance might contribute to addressing this situation

Example guidance to help address this situation could include:

  • Provide examples to illustrate the situation and potential approaches to help address the situation (similar to the examples in this document).
  • Provide examples of good practices in helping users, including users who may be non-technical, to provide accessibility features in the content they create (such as adding text alternatives).

How accessibility policies might contribute to addressing this situation

Example considerations that accessibility policies could adopt to help address this situation:

  • Define the responsibilities of content creators, owners, and providers in meeting accessibility requirements for content that may be aggregated from different sources with varying production chains and workflows.
  • Define the different types of relationships between content creators, owners, and providers that are relevant in this context, for example:
    • Content provider owns or has primary control over the content creation
    • Content provider has some control, for example contractors and suppliers
    • Content provider has little or no control, for example unaffiliated users

Situation 5: When content providers have dependencies on other services

In this situation the content provider depends on the support provided by other services, to ensure conformance of the content.

  • Example 5.1 - service using a payment service: A theater wants to sell tickets online. It ensures that accessibility is one of the key criteria during the procurement of an online payment service. Unfortunately, none of the payment service providers that are compatible with its existing reservations and accounting systems support the desired level of conformance. The theater selects a payment service provider that commits to implement all the missing accessibility requirements within X months. Until then, the theater provides an option for users who are observing accessibility barriers to contact them by phone/TTY or email, to work out other payment modalities. The theater makes this information available to users during the booking process, and ensures that other functionality conforms to the technical standard. It also indicates this accessibility limitation, as well as contact hours for phone and email booking, in an accessibility statement.
  • Example 5.2 - embedding social media channels: A start-up wants to create an online presence. It is aware of the accessibility requirements that are applicable, and so it selects a tool for creating its online presence that supports accessibility. It follows the guidance and uses the accessibility checkers provided by the tool, to ensure that the content it creates conforms to the technical standard. However, the start-up also needs to integrate social media channels in its online presence, so that it can promote itself. Unfortunately, some of these social media tools do not support the same level of conformance. The start-up makes sure that important information, such as product updates and news, are also provided directly through its online presence that conforms to the technical standard. The online presence is also programmed in such a way that accessibility issues in the social media feeds do not impact accessibility of the other content.
  • Example 5.3 - relying on content management systems (CMS): A company uses a website that allows it to create its own website. The tool provides several accessibility features, such as allowing users to indicate headings, to provide text alternatives for images, and it generates accessible markup. This was initially sufficient for the company. However, as the company website grew, the tool does not anymore provide an adequate level of accessibility support. For example, creating complex forms with the tool has conformance limitations. The company regularly files issues it finds with the tool provider, which are partially addressed at a slower pace than the company needs to ensure conformance. The company is considering to switch tools but that would be an insurmountable investment for the company at this time. The company describes the accessibility limitations in an accessibility statements and provides users with other options to complete the forms, for example through email. (Note: this example is the opposite of example 4.1; it is about shortcomings in the authoring tool that a website owner depends on.)

How technical standards might contribute to addressing this situation

Example provisions that technical standards could define to help address this situation include:

  • Define the set of accessibility requirements that can be met even under these circumstances. Examples of such requirements might include identifying and describing accessibility of the content that may (or is known to) have accessibility issues, ensuring that non-conforming content does not impede on the accessibility of other content, and providing alternative methods to accomplish tasks and complete transactions where possible (for example, providing phone/TTY or email contacts). [wording for this bullet does not yet have full consensus in the subgroup]
  • Define consistent ways for content providers to provide additional context about accessibility features and barriers in the content they provide. Examples of such context might include specifying which content may (or is know to) have accessibility issues, giving descriptions of these accessibility issues, and providing the reasons for why these issues may (or are known to) occur. This context could be made available in human- and machine-readable formats.

How accompanying guidance might contribute to addressing this situation

Example guidance to help address this situation could include:

  • Provide examples to illustrate the situation and potential approaches to help address the situation (similar to the examples in this document).
  • Provide examples of good practices in indicating conforming and non-conforming content, in writing accessibility statements (in human- and machine-readable formats), and in developing prioritized plans for making content accessible over time.
  • Provide examples of good practices in selecting tools that support accessibility, including payment services, social media, and content management systems (CMS), with particular focus on small and medium-sized businesses (SMEs).

How accessibility policies might contribute to addressing this situation

Example considerations that accessibility policies could adopt to help address this situation:

  • Define the roles and responsibilities of content creators, owners, and providers, including:
    • Content provider owns or has primary control over the content creation
    • Content provider has some control, for example contractors and suppliers
    • Content provider has little or no control, for example unaffiliated user
  • Define the roles and responsibilities of tool and service providers, such as content management systems (CMS)
  • Define when content providers have dependencies on other services in ensuring conformance of the content. This could include considerations for:
    • importance of the content to the core purpose of the overall online presence (website, app, ...)
    • contractual relationship between the content provider and its dependencies
    • relative priority of the content for people with disabilities
    • size and capability of the content provider
    • potential alternatives and compromise solutions
    • applicable reasonable efforts concepts

Situation 6: Current limitations in providing the same level of conformance for live content

In this situation the content provider cannot ensure the same level of conformance for live content as for other content. This builds on considerations currently in WCAG 2 already.

  • Example 6.1 - reduced quality of captions in live content: An organization is hosting webinars. It provides real-time captioning through a professional service provider (CART). The captioning service provides a high degree of accuracy, customary for the field. Here and there words are missed and misspelled, in particular some technical terms and the names of people are not always properly captioned during the live cast of webinars. In some webinars the moderators have sufficient time to pay attention to such mistakes, and to provide corrections in real time. At other times the discussions are too fast for real time corrections, for example during Q&A sessions. The live captions are also created by humans listening to the audio and typing the captions, so they are not synchronized with the audio. When the organization publishes recorded webinars, it corrects the captions and the transcripts, and synchronizes the captions with the audio to improve accessibility.

How technical standards might contribute to addressing this situation

Example provisions that technical standards could define to help address this situation include:

  • Define separate requirements for live and pre-recorded time-based media, similar to the approach taken in WCAG 2.
  • Define where possible tolerances and quality levels for accessibility requirements, for example to distinguish between inadequate, sufficient, and good implementations of the requirements.
  • Define accessibility requirements for both live and pre-recorded time-based media. Examples of such requirements might include text alternatives and labels for buttons of the media player, keyboard support, and ensuring that media does not play automatically for longer periods or otherwise causes interference for users.
  • Define consistent ways for content providers to declare the accessibility quality levels of the live and pre-recorded time-based content they provide. For example, a content provider may declare that it provides an average of X% accuracy for captions of live audio and Y% accuracy for pre-recorded audio.

How accompanying guidance might contribute to addressing this situation

Example guidance to help address this situation could include:

  • Provide examples to illustrate the situation and potential approaches to help address the situation (similar to the examples in this document).
  • Provide explanations of the benefits and limitations of automated captions and image recognition, as well as good practices in supplementing such automation with human quality assurance.
  • Provide examples of good practices in creating and providing quality (and synchronized) captions, audio/text descriptions, transcripts, and sign-language videos.
  • Provide examples of good practices in transitioning live time-based media to pre-recorded media; for example improving the quality and synchronization of captions.

How accessibility policies might contribute to addressing this situation

Example considerations that accessibility policies could adopt to help address this situation:

  • Define when live content cannot be supported to the same conformance levels. This could include considerations for:
    • type and volume of the content in question
    • frequency in which the content is used
    • importance of the content to the core purpose of the overall online presence (website, app, ...)
    • relative priority of the content for people with disabilities
    • size and capability of the content provider
    • potential alternatives and compromise solutions
    • applicable reasonable efforts concepts
  • Define acceptable conformance levels for the different types of live content, also based on the considerations listed above. For example, the acceptable levels for healthcare content may be different than for entertainment, and the acceptable levels for time-sensitive information (such as safety alerts, announcements, and such) may be different than other types of information.

Situation 7: Current limitations in making some types of content fully conform

In this situation the content provider is encountering substantial technical challenges in making content fully conform, especially with new technologies where accessibility techniques are not yet available.

  • Example 7.1 - technology with limited support for accessibility: A company developed a virtual reality platform, including hardware and software. Users enter this immersive environment using goggles. The goggles present video, audio, and tactile information through vibrating in different patterns. Users interact with this immersive environment through the goggles and controllers they hold in their hands. The company supports accessibility to the extent it reasonably can. For example, information can be presented in multiple formats, such as using audio signals to communicate visually nearing objects. It also supports the standard mouse and keyboard interfaces of the operating system and provides a documented API to support other developers in creating custom-made controllers, including assistive technologies. Yet the company cannot conform to all accessibility requirements because there are currently no widely recognized techniques for immersive environments.
  • Example 7.2 - sensory experiences cannot be easily translated: A tourism agency wants to promote the cultural heritage of its country through an online presence. It provides high quality videos and images of nature, monuments, buildings, art works, and other artifacts. It also provides sound bites featuring local singers, musicians, and composers. It provides alternatives for all this content, including text alternatives for images and other non-text content, captions for audio content, and audio/text descriptions for video content. For example, for the image of a popular monument, the tourism agency provides short text alternatives to identify the monument. It also provides a longer text alternative to describe its shape, color, and other noticeable characteristics, as well as specific details visible to most users, such as corrosion and shadows. In addition to this, the tourism agency voluntarily provides an optional audio track for that particular image, to help convey the mood portrayed by the image. Yet despite all these efforts, it is not possible to fully convey the visual experiences from the image to other senses.
  • Example 7.3 - lack of support by assistive technologies: Screen-readers are not able to render a 3D Model. A company offers highly engaging 3D models of the human heart via WebGL, complete with a type of label to denote a sub feature exploration or information panel. The company took care to provide a list style alternative navigation for these "free floating" labels that connects to the same associated data, and provides a descriptive text for each sub feature explored. The company has also offered a 3D Printable alternative model that may optionally present a tactile or braille identifier to connect to the associated data-set. While all of these steps shows in good faith an attempt to build accessible content, there is no prescribed method to bring this type of content forward in an accessible way.

How technical standards might contribute to addressing this situation

Example provisions that technical standards could define to help address this situation include:

  • Define the set of accessibility requirements that can be met even under these circumstances. Examples of such requirements might include text alternatives and media alternatives similar to those in WCAG 2. Other approaches could include defining mechanisms for adding new accessibility requirements to the technical standard as new technologies emerge and evolve, while retaining backward compatibility to the extent possible. [wording for this bullet does not yet have full consensus in the subgroup]

How accompanying guidance might contribute to addressing this situation

Example guidance to help address this situation could include:

  • Provide examples to illustrate the situation and potential approaches to help address the situation (similar to the examples in this document).

How accessibility policies might contribute to addressing this situation

Example considerations that accessibility policies could adopt to help address this situation:

  • Define when there are technological limitations to making content conforming. This could include considerations for:
    • type and volume of the content in question
    • frequency in which the content is used
    • importance of the content to the core purpose of the overall online presence (website, app, ...)
    • relative priority of the content for people with disabilities
    • size and capability of the content provider
    • potential alternatives
    • applicable reasonable efforts concepts

Situation 8: When content is rarely used, if ever

In this situation the content provider prioritizes effort on actively used content rather than on content that is not used by the majority of users, including people with disabilities.

  • Example 8.1 - outdated content that is rarely used: An organization that publishes weather forecast reports decided to take up accessibility. It changed its internal tooling and workflows to ensure that all new weather forecasts conform to the technical standard when they are published. The logs show that hardly anyone views past weather forecast reports, and so the organization considers all forecasts older than X weeks to be legacy. Such outdated forecasts are marked to all users as legacy, for example in a banner that conforms to the technical standard. The organization decides not to prioritize retrofitting legacy forecasts published before the date in which it adopted its new approach to accessibility. The organization indicates in an accessibility statement that forecasts from before that date may have accessibility issues, and describes the types of issues that tend to occur in these forecasts. The organization also provides a mechanism for users to request conforming versions of past forecasts, for example for research purposes.
  • Example 8.2 - current content that is rarely used: An organization is continuously archiving thousands of electronic titles, including of digital books, video and audio recordings, scanned documents, and more. It ensure that those presented to the general public, for example displayed in an exhibition, conform to the technical standard. However, the majority of titles are archived and very rarely used. Occasionally, researchers, collectors, and others may be interested in the one or other title for particular reasons. These rarely accessed titles are marked to all users as archived, for example in a banner that conforms to the technical standard. The organization decides not to prioritize retrofitting archived titles, to make them conform to the technical standard. The organization indicates in an accessibility statement that archived titles may have accessibility issues, and describes the types of issues that tend to occur in these titles. The organization also provides a mechanism for users to request conforming versions of archived titles, for example for research purposes.

How technical standards might contribute to addressing this situation

Example provisions that technical standards could define to help address this situation include:

  • Define the set of accessibility requirements that can be met even under these circumstances. Examples of such requirements might include running automated retrofitting to the extend possible (for example, to back-fill missing language changes, text alternatives, and captions), indicating content without active support for accessibility, and ensuring that content without active support for accessibility does not impede on the accessibility of other content. [wording for this bullet does not yet have full consensus in the subgroup]
  • Define consistent ways for content providers to provide additional context about accessibility features and barriers in the content they provide. Examples of such context might include specifying which content does not support the same level of conformance, and the types of accessibility issues that could occur in unsupported content. This context could be made available in human- and machine-readable formats.
  • Define consistent ways for content providers to provide mechanisms for users to report accessibility issues they encounter. An example of such a mechanism might include contact information provided by the content provider in an accessibility statement.
  • Define consistent ways for content providers to provide mechanisms for users to request accessibility accommodations. An example of such a mechanism might include contact information provided by the content provider in an accessibility statement.

How accompanying guidance might contribute to addressing this situation

Example guidance to help address this situation could include:

  • Provide examples to illustrate the situation and potential approaches to help address the situation (similar to the examples in this document).
  • Provide explanations of the benefits and limitations of automated retrofitting approaches, including for language changes, text alternatives, and captions.
  • Provide examples of good practices in indicating content with and without active support for accessibility, and in writing accessibility statements (in human- and machine-readable formats).

How accessibility policies might contribute to addressing this situation

Example considerations that accessibility policies could adopt to help address this situation:

  • Define when content can be considered too rarely used to be made to conform. This could include considerations for:
    • frequency in which the content is used
    • importance of the content to the core purpose of the overall online presence (website, app, ...)
    • relative priority of the content for people with disabilities
    • previously achieved conformance with earlier versions of the standard
    • potential alternatives and compromise solutions
    • applicable reasonable efforts concepts
  • Define criteria under which individuals can request conforming versions of the content. This could include considerations for:
    • type and volume of the content in question
    • size and capability of the content provider
    • applicable reasonable efforts concepts
  • Define acceptable timelines for content providers to respond to requests for reasonable accommodation.

Situation 9: Content is experimental for all users, including people with disabilities

In this situation the content provider is experimenting with new content that is expected to have bugs for all users, including conformance bugs.

  • Example 9.1 - on-going research and development of accessibility features: A research and development lab introduced a new type of gadget on the market, which it clearly identifies as experimental. This gadget uses a natural language interface (NLI) for interaction through voice and typing. Users can also interact with the gadget through body movements that it detects via a camera and through physical interaction with the gadget, such as positioning and pushing it in different directions. The lab considered all accessibility requirements it was aware of, for example ensuring alternative modes of interaction. The gadget also supports numerous APIs, for example to allow users to interact with the gadget through desktop and mobile apps. Yet several accessibility issues may emerge when the gadget is deployed and more widely used, and that the lab is not yet aware of. For example, the first release showed that particular accessibility settings result in too many visual and audio signals. This was improved in the second release but the research and development efforts still continue, including on accessibility features.
  • Example 9.2 - prioritizing speed-to-market over product stability: A developer released a prototype that is clearly marked to all users as Beta. The developer addressed basic accessibility requirements along with other basics in security, privacy, and internationalization. The developer did not do full review of all these aspects, including accessibility, and is aware of the potential risks in terms of user experience. The developer is also aware that accessibility issues can impact specific groups of people disproportionately more than others. They prioritize accessibility issues when they are found, depending on their severity. The developer indicates their commitment to ensure accessibility in the final product in an accessibility statement, describes the current issues that it is aware of to occur or to potentially occur, and provides a mechanism for users to report any accessibility issues they encounter. The developer continually improves accessibility along with the many other aspects, and regularly updates the accessibility statement to communicate this.
  • Example 9.3 - product demo with limited functionality and accessibility: A company is developing a product iteratively, starting with a series of non-functional designs followed by a series of product demos with limited functionality. Throughout this process the company considers accessibility to the extent possible because the demos may be shared with project team members and external stakeholders with disabilities. For example, the company ensures that buttons that are essential for the purpose of the demo are properly labelled. However, since some buttons do not yet provide the intended functionality, the demo can be confusing for some users. Also, other parts of the demo might not provide the same level of accessibility. For example, the demo intended to show the "product selection" function might have accessibility issues in the "purchase" function, which is not yet ready for demo. For each demo release, the company describes the accessibility considerations and the scope of these considerations. For example, that it provides labelled buttons in the "product selection" function. It also describes the intent of the demo and known accessibility limitations, for example in an accessibility statement.

How technical standards might contribute to addressing this situation

Example provisions that technical standards could define to help address this situation include:

  • Define consistent ways for content providers to provide additional context about accessibility features and barriers in the content they provide. Examples of such context might include specifying which content may (or is know to) not support the same level of accessibility, and the types of accessibility issues that could occur in unsupported content. This context could be made available in human- and machine-readable formats.
  • Define consistent ways for content users to report accessibility issues they encounter, for example through contact information provided by the content provider in an accessibility statement.

How accompanying guidance might contribute to addressing this situation

Example guidance to help address this situation could include:

  • Provide examples to illustrate the situation and potential approaches to help address the situation (similar to the examples in this document).
  • Provide examples of good practices in writing accessibility statements (in human- and machine-readable formats).

How accessibility policies might contribute to addressing this situation

Example considerations that accessibility policies could adopt to help address this situation:

  • Define when content can be considered experimental for all users, including people with disabilities. This could include considerations for:
    • type and volume of the content in question
    • frequency in which the content is used
    • importance of the content to the core purpose of the overall online presence (website, app, ...)
    • relative priority of the content for people with disabilities
    • how accessibility bugs are addressed in relation to the impact they may have on specific groups of people
    • any systematic exclusion of accessibility versus evolving improvements
    • time-limitations for experimental content (eg. to avoid "forever beta" loop-holes)
    • size and capability of the content provider
    • potential alternatives and compromise solutions
    • applicable reasonable efforts concepts

Situation 10: Not all accessibility requirements are always applicable to all content

In this situation the content provider does not need to meet all accessibility requirements, or can meet them in different ways, depending on the audience.

  • Example 10.1 - content provided to a limited group of users only: A coach provides online training for small groups of trainees. The content for each training is different, depending on the requested training and audience. For example, handouts are provided as electronic documents and have different diagrams, tables, and information depending on the particular training. The handouts and other documents as well as video recordings from the trainings are made available online to the small group of trainees only. The coach is aware of the accessibility considerations that may be applicable. The coach collects accessibility accommodation requests ahead of each training and adapts the trainings accordingly. For example, the coach adapts exercises for people with physical disabilities, provides real-time captioning and sign-language for people with hearing disabilities, describes visual information more clearly for people with visual disabilities, and extends breaks for people with fatigue, when such accessibility accommodations are requested. The electronic documents and video recordings are also made accessible according to these requests. For example, captions, audio/text descriptions, and text alternatives for images are only provided when needed. All content made available to the public, such as the website with promotional excerpts from some of the trainings, meet the broader set of accessibility requirements.
  • Example 10.2 - content accessed by known set of user technologies: An employer provides an intranet website that is only available to its employees who are all using computers provided by the employer. For this reason, the employer knows the exact technologies being used to access the website. This includes the combinations of operating system, browser, plug-ins, and assistive technologies. The employer strives to meet all applicable accessibility requirements. However, since the employer knows the technologies being used it can optimize the code used to provide accessibility features. For example, the employer knows which HTML5 elements and WAI-ARIA attributes are or are not supported by the browsers and assistive technologies used by the employees. The employer also knows which web technologies it uses to provide the content; for example, the CSS functionality and versions of SVG that the website relies on. The website does not work well with some browsers and assistive technologies used that are used outside the intranet but it works well for the intended audience, the employees.

How technical standards might contribute to addressing this situation

Example provisions that technical standards could define to help address this situation include:

  • Define consistent ways for content providers to declare specific accessibility requirements as not applicable in the particular context in which the content is provided. Examples of such contexts might include content provided to a small group of users with known accessibility requirements.
  • Define consistent ways for content providers to declare specific technologies that the content relies on, similar to the concept of "technologies relied upon" in WCAG 2. This might include content technologies such as HTML, SVG, and SMIL, as well as browsers, assistive technologies, and such.
  • Define consistent way for content providers to declare conformance to a partial set of accessibility requirements. This might extend the concept of "partial conformance" in WCAG 2, for example to apply to situations when some accessibility requirements were deemed as not applicable or when particular technologies are relied upon.

How accompanying guidance might contribute to addressing this situation

Example guidance to help address this situation could include:

  • Provide examples to illustrate the situation and potential approaches to help address the situation (similar to the examples in this document).
  • Provide explanations of the potential drawbacks and limitations of asking audiences to request accessibility accommodations, for example situations in which audiences may not be comfortable disclosing such information.
  • Provide explanations of the potential drawbacks and limitations of providing partial conformance, for example when the content is exported or reused elsewhere from the initially anticipated context.
  • Provide examples of good practices in protecting sensitive personal data, including when obtaining, storing, and processing requests for accessibility accommodation.

How accessibility policies might contribute to addressing this situation

Example considerations that accessibility policies could adopt to help address this situation:

  • Define contexts in which accessibility requirements can be deemed not applicable. This could include:
    • closed groups with known accessibility requirements
    • access limited to known user agents and assistive technologies
    • particular language- and country-specific situations (e.g. particular assistive technologies being used)
  • Define conditions under which it is or is not acceptable to ask audience to request accessibility accommodation. For example, in relation to overall privacy and ethical considerations.

Situation 11: Small businesses face unique challenges

In this situation the content provider is small business that may not have the necessary capacity and capability to make the content fully conform.

  • Example 11.1 - business has limited expertise: A small business created an online shop using a website hosting/creating service. The business owner took good care in following the accessibility requirements that they are aware of. For example, they selected good color combinations, added text alternatives to the products they are selling, and use appropriate heading levels on the information pages. The business owner also created some forms using the forms generator provided by the website hosting/creating service. The website hosting/creating service says that the forms generator supports accessibility but the business owner is not sure if they used the correct settings to make the forms conform to the technical standard. At this time, the business owner does not have sufficient budget to get a professional front-end developer with accessibility expertise to improve the shop.
  • Example 11.2 - business has limited resources: A small business created a website for their physical store using a website used to create other websites. On this website they post pictures and videos from the promotional events they regularly hold in the store. For example, a few days ago they hosted a book signing event and took over 500 pictures and over 3 hours worth of video materials. They have permission from the attendees to post this material but they do not have the resources to provide detailed text alternatives, captions, and audio/text descriptions for all this material. Instead of not posting the material at all, they use a photo gallery tool that is said to support accessibility. It numbers each picture and video so that they can be identified. Each event is also identified by a heading and brief description of the event.

How technical standards might contribute to addressing this situation

Example provisions that technical standards could define to help address this situation include:

  • Define consistent ways for content providers to provide mechanisms for users to report accessibility issues they encounter. An example of such a mechanism might include contact information provided by the content provider in an accessibility statement.
  • Define consistent ways for content providers to provide mechanisms for users to request accessibility accommodations. An example of such a mechanism might include contact information provided by the content provider in an accessibility statement.

How accompanying guidance might contribute to addressing this situation

Example guidance to help address this situation could include:

  • Provide examples to illustrate the situation and potential approaches to help address the situation (similar to the examples in this document).
  • Provide accessibility guides and tutorials for people new to accessibility, with particular focus on small and medium-sized businesses (SMEs).
  • Provide examples of good practices in selecting tools that support accessibility, including payment services, social media, and website hosting/creating services, with particular focus on small and medium-sized businesses (SMEs).

How accessibility policies might contribute to addressing this situation

Example considerations that accessibility policies could adopt to help address this situation:

  • Define the concept of undue burden, when content providers cannot make the content fully conform. This could include considerations for:
    • type and volume of the content in question
    • frequency in which the content is used
    • importance of the content to the core purpose of the overall online presence (website, app, ...)
    • contractual relationship between the content provider and its dependencies
    • relative priority of the content for people with disabilities
    • size and capability of the content provider
    • potential alternatives and compromise solutions
    • how time-sensitive the content is
    • applicable reasonable efforts concepts
  • Define acceptable timelines for ensuring conformance of the different types of content, also based on the considerations listed above. For example, the acceptable timelines for healthcare content may be different than for entertainment, and the acceptable timelines for time-sensitive information (such as safety alerts, announcements, and such) may be different than other types of information.
  • Define measures to avoid loop-holes, such as publishing inaccessible content and removing it before the end of the grace-period.
Retrieved from "https://www.w3.org/WAI/GL/task-forces/silver/wiki/index.php?title=Substantial_Conformance/Example_Scenarios&oldid=3249"