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