Warning:
This wiki has been archived and is now read-only.
Accessibility Activity
Accessibility covers three areas:
- accessible by those with specific physical and mental needs
- also consider those who don't associate themselves with having accessibility needs (such as the elderly)
- accessible by machines (search engines)
- accessible by those using different languages
NOTE: We need to also engage with tool developers to improve the products in these areas (i.e. Inkscape bug reports, discussions, work on patches?).
Contents
Existing Documentation
Authoring Tool Accessibility Guidelines
W3C Accessibility Note on SVG (2000)
The following 8-year old W3C Accessibility Note on SVG was written for SVG 1.0 and highlights the following accessibility recommendations and possibilities in SVG:
- 2 Usage of svg:title and svg:desc elements
- 3.1 Usage of SVG shapes (svg:circle, svg:rect)
- 3.2 Reusing alternative text as graphics by using svg:tref elements
- 3.3 Reuse of graphics via svg:symbol and svg:use elements
- 3.4 Reuse of external graphics via svg:image or svg:use elements
- 4.2 Use of CSS classes
- 4.3 Use of CSS to distinguish between different media
- 4.4 Prefer svg:text elements for textual content
- 4.5 Use SVG fonts to ensure appearance of text
- 4.6 Define purely visual effects in an external SVG document and style with CSS
- ...
SVG Linearizer Internship Report And Tool
This report is a development of a RDF vocabulary that can describe the relationship of visual entities with other visual entities (Roof SitsOnTop House) and associated Java tools.
SVG Linearization and Accessibility
This is a follow-up report from the above two W3C documents.
SVGT 1.2 Spec
Section in the SVGT 1.2 spec on Accessibility Guidelines.
Title As Tooltip
Spurred on by recent <title> discussion on the SVG WG mailing list I thought I'd put some quick notes down. More tooltip thoughts from Dr. Olaf Hoffman which have not yet been incorporated below.
We can start building up a test suite. A series of Unit Tests that have the following criteria:
- test a single aspect
- have clearly defined pass/fail criteria
- have instructions embedded into the test case (using <text> and <tspan> elements)
- tests across at least the following implementations: Adobe SVG Viewer 3, Renesis 1.0-, Opera 9-, Firefox 2-, Safari 3-, Amaya 10-, Chrome 0.2-, others?
Assumptions
NOTE: The following email describes in more detail my (Jeff) current beliefs. See earlier discussions with Jonathan Chetwynd for historical purposes.
- the innermost exposed element's title should become the tooltip.
- UAs should not walk into the shadow trees of svg:use elements unless the svg:use element itself does not have a title element.
- <title> takes precedence over <desc>
- xlink:title describes the pointed-to resource
- xlink:title should take precedence over <title> and <desc>
QUESTIONS
- How to do multi-lingual <title> elements? (systemLanguage not allowed, only one <title> recommended)
- How does pointer-events factor into tooltips?
- Does the stroke constitute part of the shape (for tooltip purposes)?
Implementation Status (Current Behavior, Bugs)
For viewers/browsers see Accessibility/Viewers
Goal #1 is to get all browsers/plugins exhibiting the same basic two behaviors:
- hover over a link and the xlink:title attribute contents are displayed in a tooltip
- hover over an element and the svg:title element contents are displayed in a tooltip
Goal #2 is to explore further ways to enhance this title/desc reporting to the user:
- hierarchical title displayed as tooltip?
- how should svg:desc element contents be displayed?
Inkscape
- Version 0.46 shows greyed out fields for title and desc in the Object Properties dialog
- Fixed in 0.47:
- Bug 171024 - Ability to set title and desc elements using Object Properties window
- Bug 238093 - <title>/<desc> children of <text> elements are displayed as text in the image (problem with the above fix)
- Bug 254850 - Description field in Object Properties not properly cleared when desc not present
- Bug 246459 - Title and Description in Object Properties are missing mnemonics
- Bug 238113 - <title>/<desc> are sometimes lost
- Bug 249445 - titles and descriptions lost when saving as Plain SVG
- Bug 254857 - No way to create root-level <title> element
- Still Working on for 0.47:
- Bug 209199 - title: dialogue on save (First patch submitted 9/8)
Adobe SVG Viewer 3.03
- Does not display svg:title, svg:desc element contents as a tooltip
- Does not display xlink:title attribute contents as a tooltip
Amaya 10.x
- TODO
Lynx
- TODO
Machine Accessibility
Test Pages
We need to understand what the current state of the art is with respect to web crawlers and SVG content. Crawlers of interest:
- Yahoo
- MSN/Live
- Ask
- Cuil
Develop a series of test pages linked to on a site such that a crawler will be able to find and index the content. These pages will contain unique text phrases. Determine which test phrases are available via the search engine after enough time has passed for a crawl:
- Pure XHTML web page, test phrase in a html:p element. Results: Google, Yahoo, MSN all index the test phrase
- Pure SVG web page, test phrase in a svg:text element
- Pure SVG web page, test phrase in a svg:title element
- Pure SVG web page, test phrase in a svg:desc element
- XHTML with SVG inline, test phrase in a SVG as above
- HTML page with SVG via <object>, test phrase in the SVG as above
- HTML page with SVG via <embed>, test phrase in the SVG as above
- HTML page with SVG via <image>, test phrase in the SVG as above
Also, ask some question on web developer forums like webmasterworld.
XSLT File
One relatively safe way of getting search engines to index SVG content would be to provide the search engine developers with a XSLT file that will transform SVG content into a roughly semantic equivalent HTML file (preserving title, text as paragraphs, links and images). This would safely remove all possible script, unnecessary styling, etc and let them use their existing algorithms for HTML content.
To clarify, this is a XSLT file that we would make available to search engines that they would use internally. I would not expect this XSLT to be used by authors as that would be a major deployment hurdle.
It seems that the W3C already has XSLT to transform SVG to HTML. This is a good starting point.
This is a collection of thoughts for the XSLT, all very-much a Work-In-Progress:
- overall goal is to get to a HTML file so that Google can leverage their existing algorithms for HTML content
- svg:svg element becomes a html:html element
- if svg:title is a child of svg:svg, then convert first title into html:head with a html:title child
- convert svg:metadata+rdf into html:meta tags?
- insert empty html:body element where all other items are appended
- strip out all style information
- each svg:g and shape become a html:div
- convert svg:foreignObject that includes HTML markup into equivalent HTML markup in an iframe?
- convert svg:title and svg:desc into paragraphs
- convert each svg:image into html:img ?
- convert xlink:href into src attribute
- if svg:image has svg:desc child, convert that into alt attribute?
- if svg:image has svg:title child, convert that to title attribute?
- convert each svg:title and svg:desc into html:p element
- another option is for svg:title to become html:hX where X is some positive integer (easiest is h1 but might want to experiment with nesting level of shapes and groups)
- convert text elements into paragraphs:
- collapse svg:tspan's into the parent svg:text:
- if tspan had text-decoration="underline" or "italic", then insert html:u or html:i
- if tspan had font-weight="bold" or >= 600, then insert html:b
- use svg:tbreak to split svg:text into two svg:text (SVGT 1.2 only)
- convert svg:text, svg:textPath and svg:textArea (SVGT 1.2 only) to
- collapse svg:tspan's into the parent svg:text:
- convert each svg:a into html:a:
- convert xlink:title into title
- convert xlink:href into href
- drop all other elements and attributes not described above
- what to do with aria- attributes?
Then test the XSLT heavily on existing SVG.
Semantic Markup
Because SVG's predefined semantics, by design, are only geometric, positional, structural, stylistic, and textual, there is a need to allow authors to apply additional defined or custom semantics to SVG content. SVG can be used to depict or visually represent a wide variety of information and interfaces from different knowledge domains. Such semantics should apply not only to the rendered appearance, but also the underlying document structure and the behavior of the interactive elements.
Aria Ontologies
ARIA defines a methodology and an ontology for user interface controls, their components, and their behaviors. This can also be applied to SVG UI controls, such as sliders or other value selectors and inputs.
Additionally, SVG needs custom ontologies and behaviors for specific common use cases, such as data charts, relationship graphs, and maps.
Being able to indicate that a pie slice is a quantitative measurement and to give its value, and have it "react" the right way when adjusted (given supporting script, of course). Or marking nodes and edges on a graph of an org chart, explaining the roles and relations of the boxes and connectors. Or making a self-describing graphical subway map.
Making a standardized vocabulary to facilitate this, and to making object-oriented graphics that can be used with script in an accessible way, would go a long way toward enabling the next generation of the Web.
Because rendering order of text in SVG is based on position attributes and not on document order, it may also be useful to develop a small ontology to allow a author to define a default reading order for text content in an SVG file.
'role' attribute
The XHTML Role Attribute Module defines an attribute intended to allow an author to include semantic information regarding the purpose of an element or elements, with the goal of meeting the needs of accessibility, device adaptation, server-side processing, and complex data description. Combined with ARIA's ontology, this can be used to add semantics in a structured way.
'access' module
The XHTML Access Module defines an element that allows authors to associate specific key inputs to focus navigation between elements, based on ids or roles.