SVG Accessibility Task Force Meeting, 17 April 2015, Minutes

The HTML-formatted minutes from Today's call are here:
http://www.w3.org/2015/04/17-svg-a11y-minutes.html

Pasted below for the archives
__________________________________________

- DRAFT -

SV_MEETING_TITLE

17 Apr 2015

See also: IRC log

Attendees

Present Jason White, Fred Esch, Doug_Schepers, AmeliaBR
Regrets
Chair fesch
Scribe AmeliaBR

Contents

Topics

actions
Open Actions
Accessibility of dynamically-updating graphics
Rich's Navigation Proposal

Summary of Action Items

________________________________

actions

<fesch> zakim: action-1584

https://www.w3.org/wiki/SVG_Accessibility/People_and_Issues

Open Actions

<fesch> action-1584

<trackbot> action-1584 -- Fred Esch to Put together use cases and
requirements for deaf and hard of hearing people. -- due 2015-02-20 -- OPEN

<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1584

FE: Wants feedback, review of his use case for deaf and hard of hearing.

https://www.w3.org/wiki/SVG_Accessibility/People_and_Issues#Users_who_are_Deaf_or_hard_of_hearing

ABR: I think that's okay. We really want to piggyback on HTML for
audio/video
... these elements in SVG are already defined in terms of HTML 5

FE: So the document looks okay?

ABR: Yep, that about sums it up

<fesch> action-1602

<trackbot> action-1602 -- Jason White to Find some stem graphics to
consider as use cases -- due 2015-03-27 -- OPEN

<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1602

JW: I've been writing a draft document, which identifies various classes of
graphics from Science & Tech fields
... not actually my background, but I've been compiling from various
documents about the technical problems of different types of diagrams
... I'm not specifically making any recommendations for a taxonomy; I'm
just summarizing different types of content that needs to be considered
from the perspective of navigation.
... Will probably overlap with the work being done for charts taxonomy.

FE: Have you found any good SVG examples?

JW: I haven't really been looking for them yet. I've been looking at a look
of books and other published material.

FE: I've been trying to put together taxonomy roles and alternative text
ideas. So, any SVG examples -- or your draft text -- send me a copy?

JW: Another area that we need to think of is interactive simulations.

<fesch> action-1603

<trackbot> action-1603 -- Charles McCathie Nevile to Work with jasonw,
markkuh and the universe to discover how people do interaction… -- due
2015-03-27 -- OPEN

<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1603

JW: I can send a link to the list about the sort of work we've been doing
on interactive simulations.
... I was in a discussion this week with people working on these; they're
definitely interested in making them accessible.

Accessibility of dynamically-updating graphics

FE: How should we handle something -- like a CPU activity monitor -- that
is constantly changing?

JW: People always need to read it without being interrupted by updates. It
depends on what type of accessibility we're talking about (e.g. auditory or
visual). But there are various cues where you can subtly update, e.g.
different tones.

<shepazu> http://www.w3.org/TR/wai-aria/states_and_properties#aria-valuenow

<shepazu> aria-valuemax, aria-valuemin, aria-valuenow

DS: This is basically a gauge: a passive range "output" of values in a range
... as jason said, you could use sonification to give different values a
different tone. this is apparently used in surgery to give feedback from
the various machines, without the surgeon having to look up.
... If someone wanted to look up more details, you'd use these aria
properties; they'd just be read-only

ABR: There are also instructions within ARIA, such as aria-live: polite, to
avoid having interruptions when you're trying to read it the first case

JW: In many cases, you'd just want to read it once

DS: Yes, you'd also want it to be easy to navigate to, so someone could
check on the current value of the gauge frequently. Maybe the sonification
tone suddenly changed, and now they need to know the details.
... The sonification takes care of the monitoring aspect, but then they'd
need to access `aria-valuenow`. But you'd need a quick way to navigate to
it?
... (To Jason): Do current implementations allow you to navigate to the
item that just provided an aria-live type update?

JW: Not that I know of.

FE: But this is more of an implementation thing.

DS: But we need to make sure there are the tools to provide this.
... A sighted user with a pointing device, when monitoring something can
always easily navigate to it
... But we really need something like an access key to jump to things

JW: You could do this with keyboard event handlers

DS: But there's no easy, declarative way

JW: I think there's still lots of dissatisfaction with the HTML access key
spec
... Also, in many cases if there is semantic navigation (e.g. from a screen
reader) that can take care of it

Rich's Navigation Proposal

https://www.w3.org/wiki/SVG_Accessibility/Navigation

DS: I like the focus of the document; I talked to Florian Rivoal (editor of
CSS UI Level 4) about the idea of having a "focusable" CSS property

FE: To set focus on an element in CSS?

ABR: More to say whether something *could* achieve focus.

DS: HTML TabIndex is a bit backwards. Originally, the idea was that authors
would control the exact order, by setting tabIndex numbers.
... but most people just use 0, 1, -1, and let the browser handle exact
order.
... The idea of a focusable property would just set those options, and you
wouldn't have to edit every element in the markup.
... I'd like to set up a meeting with Florian to talk about this.

FE: I like the idea, but I'd also like to have it automatically that, if
you set a role on an element, it is automatically focusable without
changing anything else

DS: But not all roles *should* be focusable. Or maybe their children
should/shouldn't be focusable.
... So with focusable, the author could decide which node in the tree
should be the focusable item

FE: Should roles be inherited? Otherwise, the markup could be quite verbose.

ABR: Inheriting roles could be problematic. I think there is an idea to use
CSS-type selectors to apply roles to groups of similar elements.
... Can't find the link right now.

DS: That's a great idea. I didn't know that there was a draft.

JW: Another thing to distinguish is between the "point of regard"
navigational focus point versus the text input focus point.

DS: I struggled with this for a while. "Focus" is a generic property: when
you tab to a text field, that is both the focus (input) and the navigation
point of regard.
... But if I'm using a screen reader, and I've read on to the third
paragraph, that's the point of regard. But if I type something in (assuming
it isn't an editable paragraph), the data goes to the current focus
element, which is still the text input.

ABR: A comparison is when you're reading a web page visually, you can
scroll down without changing the focus.

JW: Basically, the idea is that you can interact with something that has
focus.

DS: I think, whether something is the focus AND/OR the point of regard,
that depends on the nature of the element. If an element is not
interactive, and you navigate to it, it will be point of regard but not
focus.
... In other cases, when you do navigate, both changes.

FE: But I think with interactive charts, it's often arbitrary which
elements are interactive or not.

DS: Imagine a bar chart, some of the bars allow you to drill down, and
there's also a Refresh button. If you navigate to a bar that can't drill
down, the focus will still say on the button.

ABR: That sounds like a bad idea...

DS: I agree that it's a terrible UI. But I want to emphasize the
distinction between focus and point of regard.

FE: But if you're navigating, and the focus identifier changes, you would
expect that to also be the interactive element.
... When someone's using a tool, and they've learnt that a certain key
causes an action, that has to match up with the element that they *think*
has the focus.

DS: I agree that it's not completely intuitive. Whether something's
interactive or not isn't tied to the :focus outline.

ABR: To go back to the original idea of a "focusable" attribute -- that
would be the author's declaration that something is interactive. Even if
its not usually interactive for the browser, the author might be handling
it with a script.

DS: But a lot of SVG is decorative, the author also needs a way to declare
which parts should be navigated to.

ABR: But we've already done that (or are doing it) with the accessible
names rules -- if there is no accessible alternative, then it is ignored by
screen readers

DS: One thing me might want to do is make focus and point of regard
synonymous in SVG -- the focus always moves with the regard

FE: Because you might want to make landmarks, like headings, focusable
without them being interactive

JW: And we can't reasonably expect the browser to always tell which
elements are interactive.

FE: E.g., if you're using Angular or other tools, the event handler is
often much higher up the DOM tree.

<fesch> yup

<shepazu_> talk to you next week, or via email! :)

JW: There are a lot of things that define whether something should be point
of regard. I think it may be useful to discuss having other ways to define
focusable. But it might be worth to set a future agenda item to discuss
Doug's idea of whether focus should always move with point of regard.

rrs, make minutes public

Summary of Action Items

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

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)

No ScribeNick specified.  Guessing ScribeNick: AmeliaBR
Inferring Scribes: AmeliaBR
Default Present: +1.703.978.aaaa, +1.609.906.aabb, Doug_Schepers, AmeliaBR
Present: +1.703.978.aaaa +1.609.906.aabb Doug_Schepers AmeliaBR

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 17 Apr 2015
Guessing minutes URL: http://www.w3.org/2015/04/17-svg-a11y-minutes.html
People with action items:

[End of scribe.perl diagnostic output]