Difference between revisions of "Accessible Graphics"
NeoPhyte Rep (talk | contribs) m (moved Accessible graphics to Accessible Graphics: Wiki convention) |
(→Doing Better: bug link) |
||
Line 25: | Line 25: | ||
=== Doing Better === | === Doing Better === | ||
There is currently a | There is currently a {{bug | id = 170340 | name=bug report | status=confirmed}} regarding adding UI support for the core SVG accessibility features. | ||
Two main issues (not yet implemented) are covered by that bug report: | Two main issues (not yet implemented) are covered by that bug report: |
Latest revision as of 14:27, 23 February 2017
How can Inkscape become the ideal tool for creating accessible SVG?
Background Links
- a rant (dead link) on SVG and Accessibility given at the latest (year?) London SVGUG meeting with plenty of links. some concepts were addressed and alpha proof of concept code developed.
- Links to primary documentation on creating accessible SVG
- SVG and accessibility (somewhat out of date): authoring guidance, SVG 1.1 appendix
- Work of the W3C Accessibility task force: work statement, wiki
What Inkscape Does Well
Some accessibility features of SVG Inkscape inherits by default, such as having text stored as machine-readable text. Others require extra effort.
As of 0.91, Inkscape:
- Allows users to set alternative text (<title> and <desc>) for graphics content in the object properties dialog.
- Sets the document-level <title> element if the user has set a title in the metadata
- Supports logical grouping of elements, and allows <title> and <desc> to be set on the group
Recently pushed to the dev branch was a fix so that text-to-path stores the original text content in an aria-label attribute, which will go a long way to preserving the accessibility of that content.
Doing Better
There is currently a {{#if: bug report | bug report (lp:170340)| lp:170340 }} regarding adding UI support for the core SVG accessibility features.
Two main issues (not yet implemented) are covered by that bug report:
- A document-level title should be required, but it is currently hard to set and there is no prompting for it.
- The language of the text (visible or alternative) needs to be easy to specify with the xml:lang attribute.
Language issues can get rather complex, and have benefits beyond accessibility, so there is a separate wiki page for them.
More advanced issues to consider:
- Ensuring that text elements are preserved in a logical reading order. This will be easier once z-index is supported, for now the aria-flowto attribute could be used to define the reading order. However, there would need to be a user interface for setting the reading order -- the order that elements are added to the graphic may not be the logical reading order.
- Adding WAI-ARIA widget roles for anything that has interactive scripting added to it.