Copyright © 2022-2024 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
The Use Cases for WCAG 3.0 document is a collection of example scenarios that illustrate complex problems in conforming to accessibility guidelines.
This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
The Use Cases for WCAG 3.0 is published as a joint effort of the Silver Task Force of the Accessibility Guidelines Working Group and of the W3C Silver Community Group. It is a work in progress, and comments are welcome as Github Issues or by email.
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.
This document was published by the Accessibility Guidelines Working Group as an Editor's Draft.
Publication as an Editor's Draft does not imply endorsement by W3C and its Members.
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 03 November 2023 W3C Process Document.
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:
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, undue burden, equivalent facilitation, and limitations on application. That is, we need to understand the context around the situations and that some of them are more technical and should be addressed in WCAG, while others are more policy related and need to be addressed in policy or regulation. Understanding this helps us approach the parts that fall within the scope of WAI.
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, undue burden, equivalent facilitation, and limitations on application. 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.
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 but is not limited to 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:
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.
Some of the key terms and concepts used in this document include the following:
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.
In this situation the content provider is committed to accessibility but, despite all efforts, virtually all software has bugs and other issues of oversight.
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.
In this situation the continually compounding content makes it prohibitive for the content provider to ensure full conformance of the entire content.
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.
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.
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.
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 content 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.
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.
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.
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.)
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.
In this situation the content provider depends on the support provided by other services, to ensure conformance of the content.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
In this situation the content provider is experimenting with new content that is expected to have bugs for all users, including conformance bugs.
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.
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.
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.
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.
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.
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.
In this situation the content provider is small business that may not have the necessary capacity and capability to make the content fully conform.
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.
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.