Notes on making the W3C process diagrams accessible

The rectrack.svg and revisedrec2.svg diagrams are taken from the 2014 version of the W3C Process Document, where they are embedded within the HTML source. rectrack-note.svg is a new extended version of rectrack.svg, intended to be added to a revision of the Process Document.

At the time of writing, revisedrec2 is the most advanced version, with changes that are yet to be ported to the others if they turn out to be good. It also has several different approaches to connecting major nodes - after some testing, I'll probably work out which one is better and use that everywhere.

Note that some browsers have different behaviour when dealing with SVG as standalone files and when it is embedded in HTML. For example, Internet Explorer reportedly can't do anything at all with standalone SVG.

To test them as code embedded in HTML, instead of standalone SVG, see below:

The graphic is a relatively simple flowchart (mathematically an example of a "directed graph"). There are 5 real states, and an implicit state, and documents can move between these states by meeting requirements that vary according to the particular transition.

Cleaning the source

The original diagram was hand-coded, and so nothing was needed beyond adding accessibility features.

The states which are represented by the nodes of the graph are links, which in the original context point to various parts of the document in which the SVG was embedded. This means they are already tabbable, and because they all contain text, have a readily generated and short accessible name.

Adding accessibility

Use title for important objects
The diagram was given title elements throughout the structure. It still needs an overall desc to be added
Use aria-labelledby for titles
To cope with poor browser support for native accessibility, aria-labelledby attributes were added to all navigable objects. They refer to both the title, and the text content
Use role="none" to hide text nodes which are explicitly referred to by aria-labelledby.
text elements were generally given role="none" unless they were part of a link, in order to stop the text appearing again in the reading order for a screenreader
fill="#fff" instead of fill="none"
Graphic objects were given a white fill instead of none, to make it easier to hover them and get tooltips generated from their title elements.
ARIA list markup
The whole diagram is treated as a list, and then each node, along with the edges leading away from it is also treated as a list. There are two "loose" g elements - the links from the implicit "no state" to become a Note or First Draft. Otherwise the nodes, which are lists are just floating within the main g which has role="list". On Safari and Yandex.browser for Mac with VoiceOver this seems to work as well as wrapping each list in an element with role="listitem".
Note: Windows browsers with JAWS do not seem to recognise items in a list unless they are explicitly marked with role="listitem" while browsers with VoiceOver seem to do so at least in some cases
Matching labelling text to the relevant path
There is a minimal use of colour to make association easier - but it is not necessary, and being low-contrast is only useful to some people anyway. Text labels are also associated by being contained within the same element in the source, and by being very close to the relevant path in the layout.
Highlight currently focused object(s)
I added a stylesheet that provides a highlight effect for currently focused or hovered items
     :focus path, :focus polygon, :focus ellipse { stroke-width: 4}
     g:hover path, g:hover polygon, g:hover ellipse { stroke-width: 4}
     :focus text, g:hover text { stroke: black; stroke-width: .5}
This should probably be restricted to apply to e.g. g[role=listitem] so it can be used more generally, but I'll have to play with that a bit more
Use links to make connections navigable
Where there are one-way connections, wrap the in a link. This makes them navigable by the keyboard, and should make it possible to explore the flowchart. Unfortunately links don't seem to work in some browsers.
Use tabindex="0" to make objects navigable.
This allows a user to explore the diagram's important components using keyboard navigation. It is helpful in conjunction with the highlighting mentioned above, but it doesn't work in at least Firefox/Mac.

Problems and discussion

These are noted against the current version of rectrack2.svg, as included below

Yandex.browser 15.4.2272 Mac OS X 10.10.5

<g role="listitem" is useless
There is no way of navigating a listitem - although that is also true for HTML <li> elements unless thay have tabindex="0"…
Following links is broken
When focused on a link to a valid internal fragment, pressing return takes the focus away, but it is unclear where it goes. The address in the URL bar does reflect the target of the link. Pressing tab again moves the focus to the first item in the taborder. If the link destination is a fragment identifier that doesn't exist, focus stays where it was.

Safari Mac OS X 10.10.5

<g role="listitem" is useless
There is no way of navigating a listitem - although that is also true for HTML <li> elements unless thay have tabindex="0"…
Semi-random tab bug
There is a bug which I cannot reproduce reliably. The result is that the image loses the tab focus, and there appears to be no reliable way to get back to the image using only the keyboard. However, a workaround I successfully applied on a single attempt was to load the same image in a new tab.
Following links is broken
There seems to be no way to follow valid internal links from the keyboard, and clicking them with the mouse seems to do nothing. Links that point to a fragment id which doesn't actually exist change the URL in the address bar, but not those that point to valid fragments.

Firefox 42.0 Mac OS X 10.10.5

<g role="listitem" is useless
There is no way of navigating a listitem - although that is also true for HTML <li> elements unless thay have tabindex="0"…
tabindex="0" doesn't work
When using the tab key to navigate Firefox only seems to focus links.
visual focus disappears if linking to an inactive element
When following a link to something that isn't itself a link, the visual focus indicator disappears. The link was clearly followed, because pressing tab brings the focus indicator back again, on the first recognised active element after the target of the link.

In order to keep keyboard navigation simple, only the nodes are tabbable. It would be nice to make it possible to move from nodes to follow any of the links that are visually represented, but Safari seems not to follow links in SVG, Firefox doesn't show that they are links, and it might make navigation more complex, so I haven't tried doing it for now.

If aria-flowto worked it would be useful, but as far as I know it works in one screenreader on two browsers on one OS - i.e. is useful only to a tiny proportion of the people who need to navigate the structure. I expect to do some more experiments using tabindex and links.

This hasn't been very carefully tested yet, so there might be lots more problems. Please file issues or Edit this document and make Pull requests!

It would be good if title-derived tooltips were easier to get for visual users. I'll probably just put a white backdrop into various groups to do this

Revisedrec2.svg embedded in HTML

Flowchart: Process for producing a W3C Recommendation First Public Working Draft - Exclusion Opportunity First WD WG Decision Director's approval Working Draft WD Publish a New Working Draft WG Decision: review needed, or No change for 6 months Advance to Candidate Recommendation Director's approval Candidate recommendation - Patent Policy Exclusion Opportunity CR Publish a revised CR Working Group Decision, Directors approval for substantive changes Advance to Proposed Recommendation Director's approval Return to Working Draft WG or Director decision e.g. for further review Proposed Recommendation - Advisory Committee Review PR Advance to Recommendation Advisory Committee Review Director's Decision Return to Working Draft AC Review, Director Decision e.g. for minor changes Return to Working Draft Advisory Committee review and Director's Decision, e.g. for further work and review W3C Recommendation REC Proposed change to a Recommendation Changes to text? No text changes: Edited Recommendation No Director'sapproval Yes Substantive changes? No substantive changes: Proposed Edited Recommendation No Director'sapproval Yes New Features? No new features - return to Candidate Recommendation No Director'sapproval Yes

Rectrack2.svg embedded in HTML

Flowchart: Process for producing a W3C Recommendation First Public Working Draft - Exclusion Opportunity First WD WG Decision Working Draft WD Publish a New Working Draft WG Decision: review needed, or No change for 6 months Advance to Candidate Recommendation Director's approval Publish as a Note WG Decision, e.g. stop work for lack of interest Publishing a Working Group Note from a document not on the Recommendation Track WG Decision to publish information Working Group Note Note Publish as a Note WG Decision, e.g. for new implementation Candidate recommendation - Patent Policy Exclusion Opportunity CR Publish a revised CR Working Group Decision, Directors approval for substantive changes Advance to Proposed Recommendation Director's approval Return to Working Draft WG or Director decision e.g. for further review Publish as a Note WG Decision, e.g. stop work for lack of interest Proposed Recommendation - Advisory Committee Review PR Advance to Recommendation Advisory Committee Review Director's Decision Return to Working Draft AC Review, Director Decision e.g. for minor changes Return to Working Draft Advisory Committee review and Director's Decision, e.g. for further work and review Publish as a Note Advisory Committee Review, Director's Decision e.g. to stop work towards a Recommendation W3C Recommendation REC