- From: Chaals McCathie Nevile <chaals@yandex-team.ru>
- Date: Mon, 12 Oct 2015 18:52:53 +0200
- To: "Fred Esch" <fesch@us.ibm.com>
- Cc: public-svg-a11y@w3.org
- Message-ID: <op.x6ejufovs7agh9@widsith.local>
Did you try the example I produced? As far as I can tell it is pretty clearly navigable with the tab key - and with screenreader navigation. THere are some issues (and more based on the state of browser and screenreader support. But it seems navigable at least. The point was to develop a pattern that would work fine for other things, like org charts - where directional navigation is about as useful to a blind user as a bicycle is to a fish… cheers Chaals On Mon, 12 Oct 2015 15:58:01 +0200, Fred Esch <fesch@us.ibm.com> wrote: > > 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). > > > 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. > > > > > >> Regards, > > Fred EschAccessibility Focal, Watson Solutions > AARB Complex Visualization Working >Group Chair > W3C SVG Accessibility Task Force > > > > "Chaals McCathie Nevile" ---10/09/2015 09:21:00 PM---On Fri, 09 Oct 2015 > 21:34:38 +0200, Fred Esch <fesch@us.ibm.com> wrote: > > > 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 EschAccessibility Focal, >Watson Solutions > AARB Complex >Visualization Working >Group Chair > W3C SVG Accessibility >Task Force > > > >> "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 meetingJoin WebEx meeting Meeting number: 645 955 799Meeting > password: w3c > > Join by phone+1-617-324-0000 US Toll NumberAccess code: 645 955 799 > > > Agenda > SVG Accessibility API Mappings >> Regards, > > Fred EschAccessibility >Focal, Watson >Solutions > AARB >Complex >Visualization >Working Group >Chair > W3C SVG >Accessibility >Task Force > > >> > >> >> >> -- > 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 > -- Charles McCathie Nevile - web standards - CTO Office, Yandex chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Monday, 12 October 2015 16:53:36 UTC