SVG Accessibility Task Force, 24 April 2015 Teleconference

Formatted minutes are here:
http://www.w3.org/2015/04/24-svg-a11y-minutes.html

Pasted below for the archives.
_________________________

- DRAFT -

Protocols and Formats Working Group Teleconference
24 Apr 2015

See also: IRC log

Attendees

PresentRegretsChairFredScribeAmeliaBR, Rich, Amelia

Contents

Topics

Joint meeting with Cognitive Accessibility TF
Infrastructure
Open actions

Summary of Action Items

________________________________

<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.

Summary of Action Items

[End of minutes]
________________________________
Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/04/24 14:00:38 $
________________________________

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]

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:

[End of scribe.perl diagnostic output]