- From: Fred Esch <fesch@us.ibm.com>
- Date: Mon, 12 Oct 2015 09:58:01 -0400
- To: "Chaals McCathie Nevile" <chaals@yandex-team.ru>
- Cc: public-svg-a11y@w3.org
- Message-Id: <201510121401.t9CE1Ig2004923@d01av02.pok.ibm.com>
Chaals,
The only working example for node/edge navigation I know of is the RAVE
charting engine. In RAVE link navigation is different for sighted and AT
users. For AT users, they used the chart shadow DOM and the links were
handled with aria-flowto relationships. In RAVE links are directional
which matches aria-flowto.
For sighted keyboard users, node/edge navigation is pretty clunky. The
user or application has to enable node/edge navigation. With node/edge
navigation enabled, we highlighted all the connections for the node so the
user would know what their alternative paths are. An application could
choose to highlight forward and reverse links differently if they wished.
One link is the 'target' link (orange in picture below) and was highlighted
differently and the node on the other side of the link (the target node)
was highlighted as well. Using a key stroke the user has to go through the
highlighted (list of) links until the link they wanted to use was
highlighted. Then use a key to select the move. Oh, and if they wanted to
move to the link rather than the node, there was a key for toggling whether
the other node or link would be moved to. This allowed the user to move
anywhere in the graph using the links, but it isn't intuitive how to do it.
We also had a back button which would undo any kind of navigation move (it
used a stack so it could be used repeatedly).
Tree graph showing keboard navigation highlighting
We did not try and make the selection of the link based on direction since
multiple links can connect at the same point on a node. For instance it is
common to see org charts where a line drops vertically from a node, turns
into a inverted T and vertical lines drop from the inverted T to other
nodes.
Departmens in advertising agencies by ss kulkanri9090 .
Regards, Fred
Fred Esch
Accessibility Focal, Watson Solutions
AARB Complex Visualization Working Group
Chair
W3C SVG Accessibility Task Force
IBM Watson
From: "Chaals McCathie Nevile" <chaals@yandex-team.ru>
To: Fred Esch/Arlington/IBM@IBMUS
Cc: public-svg-a11y@w3.org
Date: 10/09/2015 09:21 PM
Subject: Re: Agenda October 9, 2015 SVG accessibility task force
On Fri, 09 Oct 2015 21:34:38 +0200, Fred Esch <fesch@us.ibm.com> wrote:
Chaals,
I am leery of navigation using node/edge relationships. Our experience has
been mixed.
So I started to work up
http://svg-access-w3cg.github.io/use-case-examples/composed-tree-links.svg
As I am writing, it only has the first two nodes done - for the example I'm
just manually grouping and recalculating stuff that a programmer would make
software do.
Since I am leery of ARIA, I tried to make it more basic. I have made the
edges into normal links, to wherever they point.
The result is that I can navigate at least the first little bit in Yandex
browser on mac without having a screenreader at all - and even see where I
am and where I am going. With Safari I can navigate it slightly more nicely
with VoiceOver running, but not at all without, and with Firfox I can
navigate it with or without but I get too little useful info about where I
am unless VO is on.
The way it is set up at the moment, I can use the voiceover cursor for a
breadth-first treewalk, or tab around the nodes and links so I can get down
the tree faster by following the path I want.
All using standard stuff: tab, return to follow links, and the basic
VoiceOver cursor movements.
The one restriction on this is that it assumes directed graphs - it uses
document order, and going backwards is tricky (the back button only sort of
works :( ). So it's still not there, but it seems a path worth exploring.
Adding a reverse link isn't rocket surgery, and nor is working with the
history API to make back work as expected without further messing with user
controls.
For users of assistive technologies, node/edge graphs are simpler to
handle. When we built the chart's shadow DOM we used aria-flowto.
Do you have an example? I tried that (in a very quick "effort"), and
couldn't make it work reliably.
We also provided a keystroke that popped up a dialog to tell you where you
were in the chart - similar to bread crumbs. Large network diagrams are not
AT user friendly, there is no good way for a AT user to work their way
through large network diagrams.
Why not add actual breadcrumbs? That's essentially what I've done with the
titles/labels (modulo my earlier concern about how labels are calculated).
As far as using tables goes, I think it is good to have a table view of a
chart, especially if you think users would like to sort the table based on
a column.
Right. Indeed, many bar/pie/scatter charts and quite a lot of line charts
are really just automatically generated representations of tables. For the
ARIA case (which is screenreader specific) it makes sense to be able to
move around the graphic, but get information that corresponds to the
underlying table. The graph ust expects you to figure out how to read that
for yourself -as does a table, although we are so used to reading tables we
often forget having to learn how they worked. If you want a reminder, look
at detailed log tables which rely on indirection - the paper equivalent of
hypertext…
However, tables are not replacements for graphics. Maps, blueprints and
instructional diagrams don't translate to tables.
Sure. Well, some instructional diagrams translate to lists, which are just
a special case of tables… but your point holds and I didn't mean to suggest
otherwise - tables are only useful for certain kinds of information.
cheers
Regards, Fred
Fred Esch
Accessibility Focal, Watson
Solutions
AARB Complex Visualization Working
Group Chair
W3C SVG Accessibility Task Force
IBM Watson
Inactive hide details for "Chaals McCathie Nevile" ---10/09/2015 09:32:54
AM---Regrets. I have some concerns about the name and"Chaals McCathie
Nevile" ---10/09/2015 09:32:54 AM---Regrets. I have some concerns about the
name and desc calculations, specifically
From: "Chaals McCathie Nevile" <chaals@yandex-team.ru>
To: public-svg-a11y@w3.org, Fred Esch/Arlington/IBM@IBMUS
Date: 10/09/2015 09:32 AM
Subject: Re: Agenda October 9, 2015 SVG accessibility task force
Regrets.
I have some concerns about the name and desc calculations, specifically
that what we are doing is locking in the currently-implemented stuff, which
is about the minimal useful thing, in a way that makes it very hard for
people to actually do anything better. I am still thinking through it -
working from a set of modifications to an algorithm is pretty nightmarish,
so editorially I would request that the spec at least copy the relevant
pieces from core mappings as an informative complete statement.
Separately I have been working on examples, as per recent emails to the
list. A couple of points:
role="img" isn't implenented according to what the spec suggests, but
rather according to the proposed role="symbol". Maybe we should recognise
that and update accordingly in both the graphics stuff and core aria.
Thinking about how to represent bar charts and the like, it strikes me that
they are simple tables - even the ones that have distributions - a solid
bar, and maybe a narrower bar covering the range of outlying values. This
also applies to scatter plots. So it seems that the easy win is just to use
aria table markup directly, instead of trying to invent new stuff. The
trick Doug used of presenting legends with simple bar charts is worth
promoting, especially if we enhance it somewhat with simple aria like using
hidden on the axes' ticks. (Having the axis itself with a title for its
range seems helpful as a summary.
And I have been thinking about navigating trees and "graphs" - the linked
nodes you get from e.g. RDF diagrams, flowcharts, schematic maps, circuit
diagrams and so on. I have some ideas I want to work up. I'll start with
the diagram [1] from the shadow DOM spec, because that gets published by
W3C and the editors are taking in my improvements [2]. Walking the nodes
works at least in Yandex/Voiceover and Firefox/Voiceover on Mac, but I
think still crashes Safari/VO and Léonie reports little joy on Windows.
The two initial strategies that seem promising are having the "edges" - the
lines between things, as links, and offering a breadth-first walk of the
nodes, at least for trees. The alternative is to make a node plus its
outward links into a group, and use aria-flowto, as I tried to do in the
chemistry example [3]. The problem is that the implementation of flowto
seems to be pretty minimal, and it isn't communicated anywhere except
through the accessibility API so you may need a screenreader running to
make sense of the navigation.
[1] http://svg-access-w3cg.github.io/use-case-examples/composed-tree.html
[2]
https://github.com/w3c/webcomponents/blob/60b7e479e86893af722c76bb26cfba6ba1341144/assets/images/composed-tree.svg
[3] http://svg-access-w3cg.github.io/use-case-examples/chem-BV-ox.html
cheers
On Thu, 08 Oct 2015 14:41:40 +0200, Fred Esch <fesch@us.ibm.com> wrote:
MEETING TIME - 10 AM US Eastern
Join WebEx meeting
Join WebEx meeting Meeting number: 645 955 799
Meeting password: w3c
Join by phone
+1-617-324-0000 US Toll Number
Access code: 645 955 799
Agenda
SVG Accessibility API Mappings
Regards, Fred
Fred Esch
Accessibility Focal, Watson
Solutions
AARB Complex Visualization
Working Group Chair
W3C SVG Accessibility Task
Force
IBM Watson
--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com
--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Monday, 12 October 2015 14:01:53 UTC