Re: Agenda October 9, 2015 SVG accessibility task force

On Mon, 12 Oct 2015 22:41:20 +0200, Fred Esch <fesch@us.ibm.com> wrote:

>
> Chaals,
>
> I find your example intriguing and am amazed that something can work  
> with tab and the enter key alone. Tab and shift + tab are predictable.  
> But there is no reverse for the enter key which >if the focus is on a  
> link takes you to the connecting node. So if you want to move backward,  
> your only choice is to shift+tab through everything. Are you trying to  
> make reverse links work?
I'm thinking about it. One approach I considered was using a history  
stack. That does a pile of good things, including being implementable  
without touching the UI behaviour - i.e. I can do it on semantic stuff  
like focus and the user going back in history. But it means a JS library  
to follow the user, going back from the page itself gets hard without a  
"rewind" button like Vivaldi (or old versions of Opera).

The simplest alternative might be to add reverse links. It is the approach  
I was considering for chord.svg too  
(<https://github.com/SVG-access-W3CG/use-case-examples/blob/master/chord.svg>).  
But clarifying visually what that means isn't so clear - you need  
something to be focused. Oh for SVG connectors…

Within the aria world (i.e. when I turn on a screenreader) I have now got  
list structures, so it *should* be possible to move up and down the list  
levels. But in practice implementation is pretty poor. :(

cheers
>
>
>
>
>> Regards,
>
> Fred EschAccessibility Focal, Watson Solutions
> AARB Complex Visualization Working >Group Chair
> W3C SVG Accessibility Task Force >

>
>
> "Chaals McCathie Nevile" ---10/12/2015 12:53:11 PM---Did you try the  
> example I produced? As far as I can tell it is pretty clearly navigable  
> with the t
>
> From: "Chaals McCathie Nevile" <chaals@yandex-team.ru>
> To: Fred Esch/Arlington/IBM@IBMUS
> Cc: public-svg-a11y@w3.org
> Date: 10/12/2015 12:53 PM
> Subject: Re: Agenda October 9, 2015 SVG accessibility task force
>
>
>
> 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
>



-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com