Accessibility Issues

From SVG

Feedback from Rich Schwerdtfeger from IBM

Structure

  • There needs to be for and SVG author or an assistive technology to separate the wheat from the chafe in content. Like Canvas or any GUI there are drawing objects in SVG that when rendered should be ignored by an assistive technology. There needs to be a way to decide how to ignore it.

Rendering

  • There needs to be a mechanism for an SVG author to detect high contrast mode or other system color changes so that an SVG drawing can be rendered accordingly

Events and UI

  • SVG should be able to respond to the device independent events like those in Web Events and PF working groups.

Text Selection and Editing

  • Like Canvas, there needs to be a way for the author to supply caret, selection position, and focus bounds information to an accessibility API
  • Less important but not critical - we should expose platform blink rates to the application developer
  • We need to look at SVG text to see that it can fully be mapped to platform accessibility APIs

Zoom

  • There needs to be a way to provide the bounds of an object to platform accessibility APIs
  • One of SVGs key advantages over canvas is the ability to zoom without degradation. We need to be able to do this relative to the point of focus

Navigation

  • Provide a keyboard navigation that is consistent with HTML that may house the SVG object. For example, a user needs to be able to tab into, through and out of SVG. You need to decide how that impacts your current keyboard navigation model what is also powerful.
  • We need to ensure that ARIA landmarks, in SVG, can be mapped to browser landmark navigation (coming in future browser releases)

Accessibility API Hooks

  • SVG needs to provide structural semantics defined by the native language to allow an assistive technology to be able to supply contextual information in an alternative rendering such as speech
    • Structural semantics is derived from the DOM plus added structural/contextual semantics from ARIA (aria-owns, aria-setsize, aria-posinset, etc.). Either a separate shadow DOM or it must be derived from the SVG DOM
    • There are benefits of providing this capability through the SVG DOM directly vs. the canvas strategy that relies on the use of HTML fallback content. Canvas authors having to maintain a shadow DOM have, to some degree double duty, yet the also benefit from ATs already supporting the HTML DOM,
  • SVG Accessibility API mappings are either inconsistent or non-existent across the browsers. This needs to be defined like we are doing for ARIA and HTML 5
  • Define a way to process selected content in SVG so that the selected content is interoperable with assistive technologies through the platform accessibility APIs.
  • The above efforts will allow SVG to be interoperable with most existing accessibility API today. However, we need to look at the host language and create a new taxonomy for drawings that conveys drawing types (roles) and their states and properties and either place them in the SVG host language or in ARIA. In some cases you may want to have an SVG element vs. a role. This work may result in us having to create new platform accessibility API extensions to all the platforms and ARIA extensions. There are ways to make this happen and I can help with that.
  • Include key ATs in the implementation plans. One of the challenges SVG will have is ATs use a mix of the HTML DOM and platform accessibility APIs on Windows. We need to make sure that ATs are aligned with SVG interoperability plans (markup to API).
Retrieved from "https://www.w3.org/Graphics/SVG/WG/wiki/index.php?title=Accessibility_Issues&oldid=2741"