Accessibility

The following summary has been stolen (with very minor formatting amendments) from the Introduction to Web Accessibility page of the W3C Web Accessibility Initiative site:

Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically, people can: perceive, understand, navigate, and interact with the Web; and contribute to the Web.

Web accessibility encompasses all disabilities that affect access to the Web, including: auditory; cognitive; neurological; physical; speech; visual; etc.

Web accessibility also benefits people without disabilities, for example:

The purpose of this page in the SC Developer Runbook is to look at (some of) the best practice recommendations for creating accessible websites, in particular around how <canvas> elements in the web page can weaken the chances of meeting those recommendations.

This page also considers the functionality repo-devs have built into Scrawl-canvas to help mitigate those weaknesses, and what further work can be done.

tl;dr: SC does not solve the (many!) accessibility issues that <canvas> elements introduce into a web page; it only tries to make the work of solving those issues as easy as possible for designers and dev-users. A poorly conceived, designed and coded SC <canvas> display IS NOT an accessible <canvas> display!

Key documentation links:

Current guidelines documentation links:

For the future – WCAG 3 drafts links:

Accessibility legislation links:

Impact of WCAG requirements on <canvas> elements

No formal guidelines exist for making the HTML5 <canvas> element accessible. Yet the need to make canvas-based displays, animations and applications more accessible is widely accepted:

(Note that online searching for standards, essays and investigations around canvas accessibility is made harder by the existence of the Canvas LMS SAAS offering, used widely by schools and colleges. More recently OpenAI launched a product called Canvas which doesn't help the search for relevant information. Not forgetting, of course, the Canva design studio thing.)

Scrawl-canvas is a JavaScript library for working with the HTML5 <canvas> element. The library:

Given that one of the stated aims of the SC library centres on making <canvas> elements more accessible, and accepting the dearth of guidance around how this can be achieved, it necessarily becomes the responsibility of repo-devs to identify those accessibility issues and make best effort to add functionality to the library to help address them.

tl;dr: The following comments on the application of WCAG Requirements with respect to the <canvas> element are the (opinionated) views of the SC repo-devs, currently unsupported by evidence from researchers, experts and users of accessibility tools and technology. If these opinions are misguided or wrong, please raise an issue in the SC GitHub repository for discussion and action.

Text alternatives for non-text content

Text alternatives are equivalents for non-text content. Examples include:

Text alternatives convey the purpose of an image or function to provide an equivalent user experience. For instance, an appropriate text alternative for a search button would be “search” rather than “magnifying lens”.

Text alternatives can be presented in a variety of ways. For instance, they can be read aloud for people who cannot see the screen and for people with reading difficulties, enlarged to custom text sizes, or displayed on braille devices. Text alternatives serve as labels for controls and functionality to aid keyboard navigation and navigation by voice recognition (speech input). They also act as labels to identify audio, video, and files in other formats, as well as applications that are embedded as part of a website.

1.1.1 (A) – Non-text Content

SC and <canvas> element children

The HTML specification for the <canvas> element permits the element to contain mainly phrasing content, though it specifically excludes interactive content except for: <a> and <button> elements; and <input> elements whose type attribute is checkbox, radio, or button.

The HTML markup placed between the <canvas> element's opening and closing tags is known as its fallback content. This is the main approach to making the <canvas> element accessible. Decisions about what markup to include in this fallback content need to be made by the designer and dev-user as they develop the web page.

Designers and dev-users should consider supplying an image of the canvas display as minimal fallback content. Many of the SC test demos include example code for such approaches – for instance see test demo Filters-006.

SC performs significant work when importing a <canvas> element into the SC system, which includes mutating the element's DOM markup and adding SC-specific child elements to its fallback content. This work has been documented in the Canvas artefact notes section of the Artefacts and the DOM page of this Runbook. These changes will not replace or modify any existing fallback content that has been defined for the element, nor do they prevent the dev-user from adding, manipulating or deleting such content after SC completes its import work.

To summarise, SC adds the following markup to the <canvas> element as part of the import functionality:

<canvas

  [... other existing attributes]

  style=[...SC styling markup string]
  title=[...SC title string, default: ""]
  role=[...SC role string, default: "img"]
  aria-labelledby=`${canvas.id}-ARIA-label`
  aria-describedby=`${canvas.id}-ARIA-description`
>

  [...Existing fallback content markup]

  <nav
    id=`${canvas.id}-navigation`
    aria-live="polite"
    aria-busy=[...Update status boolean]
  >
    [...SC-generated navigation-related content]
  </nav>

  <div
    id=`${canvas.id}-text-hold`
    aria-live="polite"
    aria-busy=[...Update status boolean]
  >
    [...SC-generated graphical text content]
  </div>

  <div
    id=`${canvas.id}-canvas-hold`
    aria-hidden="true"
    style="display: none;"
  >
    [...Reserved by SC for various purposes eg: text measurement]
  </div>

  <div
    id=`${canvas.id}-ARIA-label`
    aria-live="polite"
  >
    [...SC-generated label content, default: `${canvas.id} canvas element`]
  </div>

  <div
    id=`${canvas.id}-ARIA-description`
    aria-live="polite"
  >
    [...SC-generated description content, default: ""]
  </div>

</canvas>

Canvas label, description and title

<canvas> elements should always be provided with meaningful labels (via aria-label or, preferably, aria-labelledby attributes); consider these to be the canvas equivalent of the <img alt="accessible summary of image"> markup.

Descriptions can add supplementary details about what the canvas does, such as a summary of the data contained in a chart, or keyboard shortcuts for interactive canvas functionality. However a better approach would be to supply such information in the text surrounding the <canvas> element as this allows end-users not using accessible technologies to also see/read the information.

The title attribute is defined in the HTML specification as global, thus available on all HTML elements. However the attribute comes with significant accessibility concerns – the general advice is to avoid using it to convey information to the end-user.

Dev-users can tell SC to add labels, descriptions and titles to a <canvas> element by adding the following attributes to the element's HTML markup:

<canvas
  id=[...canvas element's unique id string]
  width=[...canvas width]
  height=[...canvas height]

  data-scrawl-canvas

  data-label=[...accessible label string]
  data-description=[...accessible description string]

  title=[...title string]
>
  [...fallback content markup]
</canvas>

Once SC has finished importing the <canvas> element into the SC system, dev-users can change the values of the <div> elements containing the label and description strings using normal SC set() functionality. When the update occurs in the DOM the affected <div> element's aria-busy attribute will be set to true, then set back to false when the update completes. The change will be announced to the end-user politely:

<script>
  [...other code]

  canvas.set({
    label: [...new label string]
    description: [...new description string]
  });
</script>

WARNING: Dev-users should never attempt to set or update the label and description <div> elements directly! Nor should these elements be removed from the DOM – do not be tempted to update the <canvas> element's contents using .innerHTML=[...new markup] or similar functionality.

Canvas roles

The role of a <canvas> element can vary depending on how it is being used in the web page.

SC, by default, will assign an imported <canvas> element to the ARIA img role. For the most part this seems to work reasonably well with screen reader technology. This is because while most screen readers will consider the element with role="img" set on it to be like a black box (and not access the individual elements inside it), they are far more likely to just disregard the <canvas> element when they encounter it and process its fallback content instead.

However <canvas> elements are eminently adaptable; dev-users can find many use cases for them. Thus it is important for designers and dev-users to carefully consider the work being done by each canvas display in the web page and adapt the element's role value accordingly:

Dev-users can set a <canvas> element's role attribute in the normal way. While SC includes functionality to update the attribute after the canvas import completes, this is (almost certainly) not best practice:

<canvas
  id=[...canvas element's unique id string]
  width=[...canvas width]
  height=[...canvas height]

  data-scrawl-canvas

  role=[...ARIA role string]
>
  [...fallback content markup]
</canvas

Captions and other alternatives for multimedia

People who cannot hear audio or see video need alternatives. Examples include:

Well-written text transcripts containing the correct sequence of any auditory or visual information provide a basic level of accessibility and facilitate the production of captions and audio descriptions.

1.2.1 (A) – Audio-only and Video-only (Prerecorded)

1.2.2 (A) – Captions (Prerecorded)

1.2.3 (A) – Audio Description or Media Alternative (Prerecorded)

1.2.4 (AA) – Captions (Live)

1.2.5 (AA) – Audio Description (Prerecorded)

1.2.6 (AAA) – Sign Language (Prerecorded)

1.2.7 (AAA) – Extended Audio Description (Prerecorded)

1.2.8 (AAA) – Media Alternative (Prerecorded)

1.2.9 (AAA) – Audio-only (Live)

SC and accessible multimedia

tl;dr: Many of the above requirements are best met during audio-visual production and post-production, long before the resulting files are supplied to the developer for inclusion in a web page. This includes generating subtitle and caption data in Web Video Text Tracks Format rather than adding them directly to the video as graphical text – which is entirely inaccessible!

SC makes it reasonably easy for dev-users to add video playback to a canvas scene. It achieves this using a set of Asset objects, which load animatable or streamed assets into the SC system and then serve them to Picture entitys and Pattern objects for display in the <canvas> element:

The requirements listed above are all concerned with making sure a web page can supply aural, visual and textual alternatives for various combinations of animated/streamed media assets. The need to meet these requirements depends on how important the asset is to the user's understanding of the web page's content:

Managing audio assets

SC does not (at this time) include any functionality to import <audio> elements as SC assets. It is up to the dev-user to find ways to import and make use of such files within the context of an SC-managed canvas display.

For the intrepid developer, check out the Web Audio API page on MDN. If that feels too overwhelming, then the awesome-webaudio page on GitHub has links to many JavaScript libraries that may help a web page meet a designer's audio-related demands.

Managing video asset captions and subtitles

SC functionality for importing video into the SC system as an asset, for use in Picture entitys and Pattern style objects, can be found in the assets page of this Runbook.

SC does not (at this time) include functionality to access or display HTMLTrackElement data. The native <video> element expects to find <track> element children placed between its opening and closing tags. The text supplied in those text tracks are not part of the video stream data itself. Instead the text tends to be displayed in normal HTML elements placed over the <video> element's display.

If dev-users want to play a user-controlled video in an SC-managed <canvas> element, then they need to implement the video controls themselves. The control inputs and buttons should (ideally!) be created using normal HTML <button> and <input> elements, though SC does not prevent the dev-user from creating them using SC entitys – see test demo Canvas-027 for a proof-of-concept example.

Similarly, dev-users can – once they have built the functionality to capture change events emitted by the video's <track> element – display those captions near to (or over) the <canvas> element, preferable in normal HTML elements or, alternatively, in SC Label and EnhancedLabel entitys.

Content can be presented in different ways

For users to be able to change the presentation of content, it is necessary that:

Meeting this requirement allows content to be correctly read aloud, enlarged, or adapted to meet the needs and preferences of different people. For instance, it can be presented using custom color combinations, text size, or other styling to facilitate reading. This requirement also facilitates other forms of adaptation, including automatic generation of page outlines and summaries to help people get an overview and to focus on particular parts more easily.

1.3.1 (A) – Info and Relationships

1.3.2 (A) – Meaningful Sequence

1.3.3 (A) – Sensory Characteristics

1.3.4 (AA) – Orientation

1.3.5 (AA) – Identify Input Purpose

1.3.6 (AAA) – Identify Purpose

SC support for the content presentation requirements

SC supports responsive canvas elements out-of-the-box, which should be good enough to meet the orientation requirement above. See the responsiveness section of the Artefacts and the DOM page of this Runbook for further details.

Canvas roles and ARIA markup are discussed in the Text alternatives for non-text content section above.

See the SC text management functionality section below for details about how SC makes graphical text in a Canvas element accessible.

Content is easier to see and hear

Distinguishable content is easier to see and hear. Such content includes:

Meeting this requirement helps separate foreground from background, to make important information more distinguishable. This includes considerations for people who do not use assistive technologies and for people using assistive technologies who may observe interference from prominent audio or visual content in the background. For instance, many people with color blindness do not use any particular tools and rely on a proper design that provides sufficient color contrast between text and its surrounding background. For others, audio that is automatically played could interfere with text-to-speech or with assistive listening devices (ALDs).

1.4.1 (A) – Use of Color

1.4.2 (A) – Audio Control

1.4.3 (AA) – Contrast (Minimum)

1.4.4 (AA) – Resize Text

1.4.5 (AA) – Images of Text

1.4.6 (AAA) – Contrast (Enhanced)

1.4.7 (AAA) – Low or No Background Audio

1.4.8 (AAA) – Visual Presentation

1.4.9 (AAA) – Images of Text (No Exception)

1.4.10 (AA) – Reflow

1.4.11 (AA) – Non-text Contrast

1.4.12 (AA) – Text Spacing

1.4.13 (AA) – Content on Hover or Focus

SC Color space support

While the use of accessible color is (almost entirely) a design issue, SC does help a little by supporting all legitimate absolute (that is, CSS Color Module Level 4) color strings – including CIELAB LCH and OKLCH color space strings. See test demos Canvas-015 and Canvas-016.

SC does not support CSS Color Module Level 5 relative colors. Dev-users can instead precalculate those colors and store them in CSS custom properties, then extract those variables into code using the JavaScript getPropertyValue() function.

Details about SC's support for wide-gamut color support – display-p3 – can be found at the linked section in the Artefacts and the DOM page of this Runbook.

SC function hooks to adapt to color-based user preferences settings

SC comes with built-in support to action changes to a canvas display based on any preference media settings – forced-colors, inverted-colors, prefers-color-scheme, prefers-contrast, prefers-reduced-transparency – that the end-user may have set on their device. This functionality has been detailed in the Accessibility section of the Artefacts and the DOM page of this Runbook.

SC support for browser zoom (not pinch zoom)

Browser implementations for zoom generally follow the pattern of modifying the browser's window.devicePixelRatio value. This has a direct impact on any <canvas> elements in the web page, which need to adapt to the user interaction as it happens, to maintain the canvas display or animation's clarity.

While SC makes a best effort to manage devicePixelRatio update functionality behind-the-scenes, dev-users are strongly advised to test any <canvas> elements they add to the page across a range of devices and screens at a variety of zoom levels.

Note that browsers operating in touch-enabled environments will generally handle user pinch-zoom gestures in a different way. SC relies entirely on the browser "doing the right thing" in such situations, and makes no effort to listen for, or react to, such events.

Functionality is available from a keyboard

Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires keyboard access to all functionality, including form controls, input, and other user interface components.

Keyboard accessibility includes:

Meeting this requirement helps keyboard users, including people using alternative keyboards such as keyboards with ergonomic layouts, on-screen keyboards, or switch devices. It also helps people using voice recognition (speech input) to operate websites and to dictate text through the keyboard interface.

2.1.1 (A) – Keyboard

2.1.2 (A) – No Keyboard Trap

2.1.3 (AAA) – Keyboard (No Exception)

2.1.4 (A) – Character Key Shortcuts

Keyboard event management for SC Canvas artefacts

The best approach to giving end-users more accessible control over a canvas display is to add a set of <input> elements to the DOM markup next to the <canvas> element, which they can then use to manipulate the canvas output. This approach makes use of the browser's built-in <input> and <select> element accessibility functionality (for selectors, ranges, etc). Many of the test demos include such controls.

Adding <input> and <select> element controls can lead to some convoluted code to wire user updates to the canvas display. SC includes two helper functions which attempt to make this a little easier for dev-users to implement and manage. More detail can be found in the user interaction with form controls section of the Events and Signals page of this Runbook:

While including input controls in the web page may often detract from the page's design and aesthetic, designers can overcome this issue by adding in methods to show/hide the controls – for instance by placing them inside a <details> element. The controls themselves can also be styled to match the surrounding content (because: they're just elements in the DOM). See test demo Canvas-023 for an example.

For more application-like interactive canvas displays – for instance: spreadsheets; monitoring/analytic consoles; image or video editing studios; design suites; etc – best practice is to include keyboard shortcuts for each of the possible interactions. To help dev-users, SC includes a keyboardZone convenience object in which dev-users can define the shortcut and associated action for the targeted <canvas> element. See the following test demos for examples:

More details about the scrawl.makeKeyboardZone() factory function can be found in the keyboard shortcut management section of the Events and Signals page of this Runbook.

Users have enough time to read and use the content

Some people need more time than others to read and use the content. For instance, some people require more time to type text, understand instructions, operate controls, or to otherwise complete tasks on a website.

Examples of providing enough time include providing mechanisms to:

2.2.1 (A) – Timing Adjustable

2.2.2 (A) – Pause, Stop, Hide

2.2.3 (AAA) – No Timing

2.2.4 (AAA) – Interruptions

2.2.5 (AAA) – Re-authenticating

2.2.6 (AAA) – Timeouts

Managing SC Animations

Each SC generic, Ticker and display animation objects includes an attribute – anim.maxFrameRate which can be used to control the speed of that animation. By default SC sets the value of this attribute to 60 frames-per-second, but this can be changed at any time using the normal anim.set() functionality. For an example, see test demo Canvas-050.

All SC animation objects can be started and stopped at any time using the anim.run() and anim.halt() functions. See the following test demos for inspiration:

SC Ticker animation objects are the only time-based animations in the SC system. There is (at this time) no simple way for the dev-user to dilate a Ticker animation (make it run faster or slower) to meet end-user preferences, but there's also nothing to prevent them changing the duration of a Ticker animation at any time.

SC Tween and Action objects can take temporal-relative String% values for their .start and .duration attributes, meaning that a Tween can be defined to start 20% of the Ticker's duration after it starts running, and last for 30% of its duration. This should make the work of dilating a Ticker animation a little easier for the dev-user.

More information about managing SC animations can be found in the Animation and Display cycle page of this Runbook.

Content does not cause seizures and physical reactions

Content that flashes at certain rates or patterns can cause photosensitive reactions, including seizures. Flashing content is ideally avoided entirely or only used in a way that does not cause known risks. Also animations and moving content can cause discomfort and physical reactions.

Examples of avoiding causing seizures and physical reactions:

2.3.1 (A) – Three Flashes or Below Threshold

2.3.2 (AAA) – Three Flashes

2.3.3 (AAA) – Animation from Interactions

SC function hooks to adapt to motion-based user preferences settings

SC comes with built-in support to action changes to a canvas display based on motion preference media settings – prefers-reduced-motion – that the end-user may have set on their device. This functionality has been detailed in the Accessibility section of the Artefacts and the DOM page of this Runbook.

Users can easily navigate, find content, and determine where they are

Well organized content helps users to orient themselves and to navigate effectively. Such content includes:

Meeting this requirement helps people to navigate through web pages in different ways, depending on their particular needs and preferences. For instance, while some people rely on hierarchical navigation structures such as menu bars to find specific web pages, others rely on search functions on websites instead. Some people may be seeing the content while others may be hearing it or seeing and hearing it at the same time. Some people may be using the content with only a mouse or a keyboard, while others may be using both.

2.4.1 (A) – Bypass Blocks

2.4.2 (A) – Page Titled

2.4.3 (A) – Focus Order

2.4.4 (A) – Link Purpose (In Context)

2.4.5 (AA) – Multiple Ways

2.4.6 (AA) – Headings and Labels

2.4.7 (AA) – Focus Visible

2.4.8 (AAA) – Location

2.4.9 (AAA) – Link Purpose (Link Only)

2.4.10 (AAA) – Section Headings

2.4.11 (AA) – Focus Not Obscured (Minimum)

2.4.12 (AAA) – Focus Not Obscured (Enhanced)

2.4.13 (AAA) – Focus Appearance

SC includes functionality to create regions in the <canvas> element display which can act as links or action buttons. These regions are defined as SC entity objects:

This approach allows SC to leverage the browser's built-in accessibility functionality for the <button> and <a> elements, including keyboard navigation and element focus/blur.

Further details of this functionality can be found in the interactive entitys section of the Scrawl-canvas graphical entity functionality page of this Runbook. Test demo examples include:

Apply canvas decoration to HTML headers using SC Snippet functionality

SC includes experimental functionality – SC Snippets – to associate a <canvas> element with normal (non-SC controlled) DOM elements. The results are similar to the Houdini CSS Painting API, though the path to achieving those results is different.

When a dev-user chooses to apply an SC Snippet to a DOM element such as a heading, then they will need to make sure that the added <canvas> does not interfere with the accessibility of the header.

Test demo Snippets-006 investigates this issue, including the need to accommodate end-user preferences (eg: prefers-dark-mode, prefers-contrast), and to include mechanisms to afford end-users control of animated effects.

Users can use different input modalities beyond keyboard

Input modalities beyond keyboard, such as touch activation, voice recognition (speech input), and gestures make content easier to use for many people. Yet not everyone can use each of these input modalities, and to the same degree. Particular design considerations maximize the benefit of these input modalities. This includes:

Meeting this requirement makes the content easier to use for many people with a wide range of abilities using a wide range of devices. This includes content used on mobile phones, tablet computers, and self-service terminals such as ticketing machines.

Note that most of the requirements below need to be managed at the design stage of website development.

2.5.1 (A) – Pointer Gestures

2.5.2 (A) – Pointer Cancellation

2.5.3 (A) – Label in Name

2.5.4 (A) – Motion Actuation

2.5.5 (AAA) – Target Size (Enhanced)

2.5.6 (AAA) – Concurrent Input Mechanisms

2.5.7 (AA) – Dragging Movements

2.5.8 (AA) – Target Size (Minimum)

Text is readable and understandable

Content authors need to ensure that text content is readable and understandable to the broadest audience possible, including when it is read aloud by text-to-speech. Such content includes:

Meeting this requirement helps software, including assistive technology, to process text content correctly. For instance, this requirement helps software to read the content aloud, to generate page summaries, and to provide definitions for unusual words such as technical jargon. It also helps people who have difficulty understanding more complex sentences, phrases, and vocabulary. In particular, it helps people with different types of cognitive disabilities.

3.1.1 (A) – Language of Page

3.1.2 (AA) – Language of Parts

3.1.3 (AAA) – Unusual Words

3.1.4 (AAA) – Abbreviations

3.1.5 (AAA) – Reading Level

3.1.6 (AAA) – Pronunciation

SC text management functionality

SC manages graphical text through the Label and EnhancedLabel entitys. In both cases the entitys, by default, replicate their text into dedicated <div> elements which are part of the <canvas> element's fallback content – thus making the text available to accessibility technologies like screen readers. These elements will announce text changes to the end-user politely.

However, not all of the text in a canvas display may be relevant to an end-user's understanding of the wider web page. For instance in a chart, it is often enough to inform the end-user of the start and end values of each axis without the need to tell them the value of each tick displayed in the chart – information which could distract them from the more important information which the chart demonstrates visually. To this end, SC allows dev-users to suppress an entity's text replication into the DOM on a case-by-case basis, controlled by the entity.textIsAccessible boolean attribute.

Furthermore, it is not enough to replicate graphical text into the DOM. That replicated text needs to make coherent sense to the end-user, which means:

To help meet these requirements SC text-related entitys include a vary simple templating system controlled by the entity.accessibleText and entity.accessibleTextPlaceholder attributes. Dev-users can set the order in which multiple text-related entitys present their text to the end-user using the entity.accessibleTextOrder attribute.

A fuller investigation of Label and EnhancedLabel entity functionality can be found in the Text-based entitys page of this Runbook.

Content appears and operates in predictable ways

Many people rely on predictable user interfaces and are disoriented or distracted by inconsistent appearance or behavior. Examples of making content more predictable include:

Meeting this requirement helps people to quickly learn the functionality and navigation mechanisms provided on a website, and to operate them according to their specific needs and preferences. For instance, some people assign personalized shortcut keys to functions they frequently use to enhance keyboard navigation. Others memorize the steps to reach certain pages or to complete processes on a website. Both rely on predictable and consistent functionality.

Note that most of the requirements below need to be managed at the design stage of website development.

3.2.1 (A) – On Focus

3.2.2 (A) – On Input

3.2.3 (AA) – Consistent Navigation

3.2.4 (AA) – Consistent Identification

3.2.5 (AAA) – Change on Request

3.2.6 (A) – Consistent Help

Users are helped to avoid and correct mistakes

Forms and other interaction can be confusing or difficult to use for many people, and, as a result, they may be more likely to make mistakes. Examples of helping users to avoid and correct mistakes include:

Meeting this requirement helps people who do not see or hear the content, and may not recognize implicit relationships, sequences, and other cues. It also helps people who do not understand the functionality, are disoriented or confused, forget, or make mistakes using forms and interaction for any other reason.

Note that most of the requirements below need to be managed at the design stage of website development.

3.3.1 (A) – Error Identification

3.3.2 (A) – Labels or Instructions

3.3.3 (AA) – Error Suggestion

3.3.4 (AA) – Error Prevention (Legal, Financial, Data)

3.3.5 (AAA) – Help

3.3.6 (AAA) – Error Prevention (All)

3.3.7 (A) – Redundant Entry

3.3.8 (AA) – Accessible Authentication (Minimum)

3.3.9 (AAA) – Accessible Authentication (Enhanced)

Content is compatible with current and future user tools

Robust content is compatible with different browsers, assistive technologies, and other user agents. Examples of how this can be achieved include:

Meeting this requirement helps maximize compatibility with current and future user agents, including assistive technologies. In particular, it enables assistive technologies to process the content reliably, and to present or to operate it in different ways. This includes non-standard (scripted) buttons, input fields, and other controls.

Note that the issues raised below, as they relate to SC Canvas artefacts, have already been discussed above.

4.1.1 Parsing (Obsolete and removed)

4.1.2 (A) – Name, Role, Value

4.1.3 (AA) – Status Messages