IRC log of svg-a11y on 2015-04-17

Timestamps are in UTC.

13:01:57 [RRSAgent]

RRSAgent has joined #svg-a11y

13:01:57 [RRSAgent]

logging to http://www.w3.org/2015/04/17-svg-a11y-irc

13:03:02 [fesch]

chair: fesch

13:03:34 [fesch]

zakim, chair: fesch

13:03:37 [Zakim]

I don't understand 'chair: fesch', fesch

13:04:54 [fesch]

topic: actions

13:05:12 [fesch]

zakim: action-1584

13:06:21 [AmeliaBR]

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

13:06:54 [AmeliaBR]

zakim, who's on the call?

13:06:54 [Zakim]

sorry, AmeliaBR, I don't know what conference this is

13:06:56 [Zakim]

On IRC I see RRSAgent, Zakim, fesch, AmeliaBR, trackbot, shepazu, MichaelC, ed

13:07:22 [AmeliaBR]

zakim, this is 2742

13:07:22 [Zakim]

ok, AmeliaBR; that matches WAI_SVGTF()9:00AM

13:07:27 [AmeliaBR]

zakim, who's on the call?

13:07:27 [Zakim]

On the phone I see ??P13, +1.703.978.aaaa, +1.609.906.aabb, Doug_Schepers

13:07:40 [AmeliaBR]

zakim, ??P13 is me

13:07:40 [Zakim]

+AmeliaBR; got it

13:09:02 [fesch]

Topic: actions

13:09:02 [AmeliaBR]

TOPIC: Open Actions

13:09:22 [fesch]

action-1584

13:09:22 [trackbot]

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

13:09:22 [trackbot]

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

13:10:05 [AmeliaBR]

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

13:10:06 [AmeliaBR]

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

13:10:53 [AmeliaBR]

ABR: I think that's okay. We really want to piggyback on HTML for audio/video

13:11:24 [AmeliaBR]

... these elements in SVG are already defined in terms of HTML 5

13:11:37 [AmeliaBR]

FE: So the document looks okay?

13:11:45 [AmeliaBR]

ABR: Yep, that about sums it up

13:12:53 [fesch]

action-1602

13:12:53 [trackbot]

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

13:12:53 [trackbot]

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

13:13:31 [AmeliaBR]

JW: I've been writing a draft document, which identifies various classes of graphics from Science & Tech fields

13:14:06 [AmeliaBR]

... not actually my background, but I've been compiling from various documents about the technical problems of different types of diagrams

13:14:43 [AmeliaBR]

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

13:15:10 [AmeliaBR]

... Will probably overlap with the work being done for charts taxonomy.

13:15:22 [AmeliaBR]

FE: Have you found any good SVG examples?

13:15:54 [AmeliaBR]

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

13:16:59 [AmeliaBR]

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?

13:17:31 [AmeliaBR]

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

13:17:46 [fesch]

action-1603

13:17:46 [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

13:17:46 [trackbot]

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

13:18:51 [AmeliaBR]

JW: I can send a link to the list about the sort of work we've been doing on interactive simulations.

13:19:21 [AmeliaBR]

... I was in a discussion this week with people working on these; they're definitely interested in making them accessible.

13:20:06 [AmeliaBR]

TOPIC: Accessibility of dynamically-updating graphics

13:20:40 [AmeliaBR]

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

13:22:11 [AmeliaBR]

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.

13:22:13 [shepazu]

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

13:22:50 [shepazu]

aria-valuemax, aria-valuemin, aria-valuenow

13:23:30 [AmeliaBR]

DS: This is basically a gauge: a passive range "output" of values in a range

13:24:33 [AmeliaBR]

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

13:26:28 [AmeliaBR]

... If someone wanted to look up more details, you'd use these aria properties; they'd just be read-only

13:27:31 [AmeliaBR]

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

13:27:50 [AmeliaBR]

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

13:28:40 [AmeliaBR]

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.

13:29:58 [AmeliaBR]

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

13:30:37 [AmeliaBR]

... (To Jason): Do current implementations allow you to navigate to the item that just provided an aria-live type update?

13:30:47 [AmeliaBR]

JW: Not that I know of.

13:31:07 [AmeliaBR]

FE: But this is more of an implementation thing.

13:31:36 [AmeliaBR]

DS: But we need to make sure there are the tools to provide this.

13:32:51 [AmeliaBR]

DS: A sighted user with a pointing device, when monitoring something can always easily navigate to it

13:33:11 [AmeliaBR]

DS: But we really need something like an access key to jump to things

13:33:24 [AmeliaBR]

JW: You could do this with keyboard event handlers

13:33:33 [AmeliaBR]

DS: But there's no easy, declarative way

13:34:08 [AmeliaBR]

JW: I think there's still lots of dissatisfaction with the HTML access key spec

13:34:26 [AmeliaBR]

... Also, in many cases if there is semantic navigation (e.g. from a screen reader) that can take care of it

13:34:47 [AmeliaBR]

TOPIC: Rich's Navigation Proposal

13:34:55 [AmeliaBR]

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

13:36:52 [AmeliaBR]

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

13:37:12 [AmeliaBR]

FE: To set focus on an element in CSS?

13:37:32 [AmeliaBR]

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

13:38:25 [AmeliaBR]

DS: HTML TabIndex is a bit backwards. Originally, the idea was that authors would control the exact order, by setting tabIndex numbers.

13:38:43 [AmeliaBR]

... but most people just use 0, 1, -1, and let the browser handle exact order.

13:39:36 [AmeliaBR]

... The idea of a focusable property would just set those options, and you wouldn't have to edit every element in the markup.

13:39:47 [AmeliaBR]

... I'd like to set up a meeting with Florian to talk about this.

13:40:23 [AmeliaBR]

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

13:40:50 [AmeliaBR]

DS: But not all roles *should* be focusable. Or maybe their children should/shouldn't be focusable.

13:41:45 [AmeliaBR]

... So with focusable, the author could decide which node in the tree should be the focusable item

13:44:36 [AmeliaBR]

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

13:45:06 [AmeliaBR]

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.

13:45:12 [AmeliaBR]

... Can't find the link right now.

13:46:00 [AmeliaBR]

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

13:46:34 [AmeliaBR]

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

13:47:54 [AmeliaBR]

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.

13:48:42 [AmeliaBR]

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

13:50:09 [AmeliaBR]

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

13:50:33 [AmeliaBR]

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

13:51:31 [AmeliaBR]

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.

13:51:47 [AmeliaBR]

... In other cases, when you do navigate, both changes.

13:52:11 [AmeliaBR]

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

13:52:38 [AmeliaBR]

q+

13:53:50 [AmeliaBR]

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.

13:53:59 [AmeliaBR]

ABR: That sounds like a bad idea...

13:54:27 [AmeliaBR]

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

13:55:38 [AmeliaBR]

FE: But if you're navigating, and the focus identifier changes, you would expect that to also be the interactive element.

13:56:27 [AmeliaBR]

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

13:57:29 [AmeliaBR]

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

13:59:55 [AmeliaBR]

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.

14:00:26 [AmeliaBR]

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

14:01:13 [AmeliaBR]

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

14:02:09 [AmeliaBR]

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

14:02:46 [AmeliaBR]

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

14:03:09 [AmeliaBR]

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

14:03:29 [AmeliaBR]

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

14:04:30 [shepazu_]

shepazu_ has joined #svg-a11y

14:05:12 [fesch]

yup

14:05:13 [Zakim]

-Doug_Schepers

14:05:27 [shepazu_]

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

14:05:41 [AmeliaBR]

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.

14:05:53 [fesch]

zakim, list participants

14:05:53 [Zakim]

As of this point the attendees have been +1.703.978.aaaa, +1.609.906.aabb, Doug_Schepers, AmeliaBR

14:05:53 [AmeliaBR]

zakim, list participants

14:05:55 [Zakim]

As of this point the attendees have been +1.703.978.aaaa, +1.609.906.aabb, Doug_Schepers, AmeliaBR

14:06:07 [AmeliaBR]

rrs, make minutes public

14:06:16 [AmeliaBR]

rrsAgent, make minutes public

14:06:16 [RRSAgent]

I'm logging. I don't understand 'make minutes public', AmeliaBR. Try /msg RRSAgent help

14:06:36 [AmeliaBR]

rrsAgent, make logs public

14:06:52 [AmeliaBR]

rrsAgent, make minutes

14:06:52 [RRSAgent]

I have made the request to generate http://www.w3.org/2015/04/17-svg-a11y-minutes.html AmeliaBR

14:13:50 [Zakim]

-AmeliaBR

14:13:52 [Zakim]

- +1.703.978.aaaa

14:14:05 [Zakim]

- +1.609.906.aabb

14:14:06 [Zakim]

WAI_SVGTF()9:00AM has ended

14:14:06 [Zakim]

Attendees were +1.703.978.aaaa, +1.609.906.aabb, Doug_Schepers, AmeliaBR

16:31:12 [Zakim]

Zakim has left #svg-a11y

16:44:40 [chaals]

chaals has joined #svg-a11y