<trackbot> Date: 24 April 2015

<richardschwerdtfeger> meeting: W3C SVG Accessibility Task Force

<fesch> https://lists.w3.org/Archives/Public/public-svg-a11y/2015Apr/0022.html

<AmeliaBR> Scribe: AmeliaBR

Joint meeting with Cognitive Accessibility TF

Rich: They had a F2F last week, but I willl be joining their Monday call, to make sure they have an agenda item to think about what to talk with us

<richardschwerdtfeger> coga IRC channel is #coga

Rich: Here are the logistics with respect to the CogA joint call? It is set for May 11

<richardschwerdtfeger> call in passcode is also coga

Rich: I'll send a not to Lisa to remind her of the agenda item re brainstorm for the joint meeting

Infrastructure

Fred: Charles isn't here. He had been setting things up. Not sure where the links are. We can ask Charles next week.

Open actions

<fesch> ACTION-1600 open Get with doug to build a starting navigation Léonie Watson 2015-03-27 SVG

<fesch> strategy for charts Accessibility

<fesch> ACTION-1601 open Take a look at the connector spec. and Richard 2015-03-27 SVG

<fesch> develop navigation strategy and identify Schwerdtfeger Accessibility

<fesch> semantic points of interest

<fesch> ACTION-1602 open Find some stem graphics to consider as use Jason White 2015-03-27 SVG

<fesch> cases Accessibility

<fesch> ACTION-1603 open Work with jasonw, markkuh and the universe Charles McCathie 2015-03-27 SVG

<fesch> to discover how people do interaction… Nevile Accessibility

<richardschwerdtfeger> http://florian.rivoal.net/blog/2015/04/controlling-spatial-navigation/

Rich: I've been focusing on the navigation work. Doug has offered comments, and so has Florian from CSS UI.
... I'll send this to the list right now. It's on existing work on directional navigation in SVG.

<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-svg-a11y/2015Apr/0026.html

<richardschwerdtfeger> https://www.w3.org/wiki/SVG_Accessibility/Navigation

Rich: My proposal (on the wiki) goes beyond the ability to navigate by the compass. The author would annotate what would be focusable and what would not be. More than just roles and native semantics, you'd be able to restrict it more.
... We should really have a discussion about whether we want everything to be focusable by default.
... From CSS UI, there is the `auto` value for focusable; if it is natively focusable, or if the author particular points focus to it.
... For focusable: true, I think I like what we currently have with tabIndex better. For focusable: false, it's kind of like tabIndex -1, but not quite, since there's this extra instructions about focusing to children.

Fred: I just recently set out a reply to the email list. It emphasizes that charts have features, and you usually only want directional navigation within a feature. (e.g. axis vs datapoints)
... I also mentioned that there is a hierarchical aspect of navigation in many cases.

Rich: In my proposal I didn't really address hierarchy and drilling down when it comes to focus.

<richardschwerdtfeger> scribe: Rich

<richardschwerdtfeger> Amelia: the problem is that only so many … that people to expect during focus.

<richardschwerdtfeger> Amelia: it gets complex if we introduce popups

<richardschwerdtfeger> Amelia: either you have multidirectional navigation or you have drill down. … moving in the same level

<richardschwerdtfeger> scribe Ameila

<richardschwerdtfeger> scribe: Amelia

AmeliaBR: There are only so many keys or inputs that people expect to have meaning. If you're using up/down to change levels, you can't use them for directional navigations.

Fred: We definitely ran into that issue when trying to implement it.
... But I also don't think you want to just have "go left" and you're bouncing between axes and data points.

<richardschwerdtfeger> Amelia: there could be one level of drop down where you are tabbing between major features

<richardschwerdtfeger> Amelia: tabindex has no hierarchy

<richardschwerdtfeger> Amelia: with tabindex you are operating on one level

Fred: How do you do it for sighted vs blind users. The more you rely on direction vs semantic hierarchy, the less intuitive it is for blind users.

Rich: One thing we've found with touch screens is that there are better ways to have directional navigation for non-sighted users.

Fred: But that doesn't quite make sense for navigating a bar chart or similar.

<richardschwerdtfeger> https://www.w3.org/wiki/SVG_Accessibility/Navigation

Rich: That's true, you could necessarily discover things just be touching the screen.

Fred: The problem really comes up with data-dense charts. For a sighted user, it is hard to reach the thing you're interested in, for a blind user it is hard to even find it. And some items can be obscured by others.

<richardschwerdtfeger> auto: the element is focusable according to the semantics of the

<richardschwerdtfeger> host language, or if it is the target of directional

<richardschwerdtfeger> navigation

<richardschwerdtfeger> true: the element is focusable

<richardschwerdtfeger> false: the element is not focusable. Attempting to focus it

<richardschwerdtfeger> through directional navigation focuses the first focusable

<richardschwerdtfeger> element found by traversing the dom starting on this element,

<richardschwerdtfeger> starting with its children

Rich: That was one thing mentioned in Florian's proposal (copied above). There is some author control about what comes next.

<richardschwerdtfeger> Assuming conveniently placed IDs, they can be used like this to go

<richardschwerdtfeger> solve the example given above:

<richardschwerdtfeger> #rightmost { nav-right: #leftmost; }

<richardschwerdtfeger> #leftmost { nav-left: #rightmost; }

Fred: Yes, one thing he mentioned was the idea of "rollover" navigation, from the leftmost to the rightmost.
... it wraps around instead of getting stuck to the end.
... I used this behavior on axes. If you keep scrolling to the right you loop back to the left. But I did not implement it on data elements.
... It depends on how you think of the feature and its usability. But it is a good feature.

Rich: Do people think this is a use case we should have?

AmeliaBR: I think it's great to leave it as an author-controlled feature.

Rich: For directional navigation, then, we want authors to have control over how far it can go, whether it wraps, and whether something can be focusable at all with directional navigation.

Fred: Definitely. I used `role="none"` a lot for little things like tick mark lines that would just clutter things up.

<richardschwerdtfeger> https://svgwg.org/svg2-draft/struct.html#implicit-aria-semantics

Fred: You might have both major and minor ticks, and you wouldn't want the little tick lines to grab navigation focus

Rich: With the mapping we have, if little items don't have any information, they should be mapping to `none` anyway.

Fred: But on the other side, for data points, you would add a `<title>` with the data value, and you would want that to be navigated to.

Rich: Yes, a `<title>` child element would change the default role from `none` to `group`. Would that be enough?

Fred: Yes. I've been marking up samples, to see how things work. But you really need roles to inherit for it to work.
... E.g., if you had a <g> with role="data", then all the child data points would inherit the role of data.

Rich: That's a big API change, that might be difficult to implement.

AmeliaBR: It's not so much inheritance in the CSS sense, as it is a context created from the container's role

Rich: We might have to leave this up to the ATs.

Fred: It's for all sorts of ATs, e.g., to make data items high-contrast

Rich: But we wouldn't want it to happen automatically, cause there could be other child content

Fred: Well, you could explicitly put role="none"

Jason: If only we had the proposal, which we mentioned last week, of being able to use CSS selectors to assign roles, it would be much easier

Rich: There is some work about that.

Fred: My real concern is that it's too much markup, it's much easier to just label the group, rather than every single child element.

AmeliaBR: And we have to consider ease of use. If it is too complicated to mark up a chart, people won't do it.

Rich: We are propogating states now in ARIA. E.g., you can put a row/column count on a grid, and the user agent would map that to every row.
... I agree that I'd rather not have to put a role on every tick mark. But we have to think about whether there are any cases where this could kick us in the back.

<richardschwerdtfeger> https://svgwg.org/svg2-draft/struct.html#implicit-aria-semantics

Rich: On a related topic, there are error-condition to consider. E.g., if an author makes a shape focusable, we should default to a meaningful role for that, even if they don't have any accessibility features.

Fred: This brings up a question I ran into a lot. When should you use <desc> vs <title>? E.g., for some elements, even if you have a <title>, there might be nothing that can hover to reveal that title tooltip.

AmeliaBR: E.g., you can put a title on a <g>, and it will show up when you hover child elements -- but not if the children all have their own titles.
... But I think we should focus on the semantic difference between a short title vs a longer description

Fred: But if you put a title or desc on an element, would it automatically be focusable?

Rich: It would in my proposal, but not by default.
... But I think I've checked off my action item.

Fred: One thing I would like to do is to throw out some of the marked up examples I've been working on, to see if the semantic markup and the navigation proposal really work together.
... But we really have to talk about the differences in navigation between sighted and blind users. My IBM demos had two completely different navigation schemes.
... We also need to think about markup queues that can be used for other types of accessibility issues, such as high contrast displays.
... Maybe next week we can continue to talk about which types of directional navigations can be used. And I want to talk more about chart accessibility markup. But I also want to talk with blind TF members about how we can help them understand the examples we're trying to mark up.

Rich: I will try to integrate these ideas, and the ones from Florian, in the wiki. Main ideas are that we want author control, but we don't want to make authors do too much work.

AmeliaBR: I will try to send ideas to the list. I will be at the LibreGraphics conference next week. I'll also send a note to the list about the reception to my short talk on SVG accessibility.

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Do people have/Here are the/
Succeeded: s/links are./links are.  We can ask Charles next week./
Succeeded: s/mark labels/mark lines/
Found Scribe: AmeliaBR
Inferring ScribeNick: AmeliaBR
Found Scribe: Rich
Found Scribe: Amelia
Scribes: AmeliaBR, Rich, Amelia

WARNING: No "Present: ... " found!
Possibly Present: Amelia AmeliaBR Amy_ Fred Fred_Esch Jason P28 Rich Rich_Schwerdtfeger aaaa aabb aacc auto cpandhi false fesch https joined richardschwerdtfeger shepazu svg-a11y trackbot true
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Found Date: 24 Apr 2015
Guessing minutes URL: http://www.w3.org/2015/04/24-svg-a11y-minutes.html
People with action items: