13:01:57 RRSAgent has joined #svg-a11y 13:01:57 logging to http://www.w3.org/2015/04/17-svg-a11y-irc 13:03:02 chair: fesch 13:03:34 zakim, chair: fesch 13:03:37 I don't understand 'chair: fesch', fesch 13:04:54 topic: actions 13:05:12 zakim: action-1584 13:06:21 https://www.w3.org/wiki/SVG_Accessibility/People_and_Issues 13:06:54 zakim, who's on the call? 13:06:54 sorry, AmeliaBR, I don't know what conference this is 13:06:56 On IRC I see RRSAgent, Zakim, fesch, AmeliaBR, trackbot, shepazu, MichaelC, ed 13:07:22 zakim, this is 2742 13:07:22 ok, AmeliaBR; that matches WAI_SVGTF()9:00AM 13:07:27 zakim, who's on the call? 13:07:27 On the phone I see ??P13, +1.703.978.aaaa, +1.609.906.aabb, Doug_Schepers 13:07:40 zakim, ??P13 is me 13:07:40 +AmeliaBR; got it 13:09:02 Topic: actions 13:09:02 TOPIC: Open Actions 13:09:22 action-1584 13:09:22 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 https://www.w3.org/WAI/PF/Group/track/actions/1584 13:10:05 FE: Wants feedback, review of his use case for deaf and hard of hearing. 13:10:06 https://www.w3.org/wiki/SVG_Accessibility/People_and_Issues#Users_who_are_Deaf_or_hard_of_hearing 13:10:53 ABR: I think that's okay. We really want to piggyback on HTML for audio/video 13:11:24 ... these elements in SVG are already defined in terms of HTML 5 13:11:37 FE: So the document looks okay? 13:11:45 ABR: Yep, that about sums it up 13:12:53 action-1602 13:12:53 action-1602 -- Jason White to Find some stem graphics to consider as use cases -- due 2015-03-27 -- OPEN 13:12:53 https://www.w3.org/WAI/PF/Group/track/actions/1602 13:13:31 JW: I've been writing a draft document, which identifies various classes of graphics from Science & Tech fields 13:14:06 ... not actually my background, but I've been compiling from various documents about the technical problems of different types of diagrams 13:14:43 ... 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 ... Will probably overlap with the work being done for charts taxonomy. 13:15:22 FE: Have you found any good SVG examples? 13:15:54 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 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 JW: Another area that we need to think of is interactive simulations. 13:17:46 action-1603 13:17:46 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 https://www.w3.org/WAI/PF/Group/track/actions/1603 13:18:51 JW: I can send a link to the list about the sort of work we've been doing on interactive simulations. 13:19:21 ... I was in a discussion this week with people working on these; they're definitely interested in making them accessible. 13:20:06 TOPIC: Accessibility of dynamically-updating graphics 13:20:40 FE: How should we handle something -- like a CPU activity monitor -- that is constantly changing? 13:22:11 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 http://www.w3.org/TR/wai-aria/states_and_properties#aria-valuenow 13:22:50 aria-valuemax, aria-valuemin, aria-valuenow 13:23:30 DS: This is basically a gauge: a passive range "output" of values in a range 13:24:33 ... 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 ... If someone wanted to look up more details, you'd use these aria properties; they'd just be read-only 13:27:31 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 JW: In many cases, you'd just want to read it once 13:28:40 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 ... 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 ... (To Jason): Do current implementations allow you to navigate to the item that just provided an aria-live type update? 13:30:47 JW: Not that I know of. 13:31:07 FE: But this is more of an implementation thing. 13:31:36 DS: But we need to make sure there are the tools to provide this. 13:32:51 DS: A sighted user with a pointing device, when monitoring something can always easily navigate to it 13:33:11 DS: But we really need something like an access key to jump to things 13:33:24 JW: You could do this with keyboard event handlers 13:33:33 DS: But there's no easy, declarative way 13:34:08 JW: I think there's still lots of dissatisfaction with the HTML access key spec 13:34:26 ... Also, in many cases if there is semantic navigation (e.g. from a screen reader) that can take care of it 13:34:47 TOPIC: Rich's Navigation Proposal 13:34:55 https://www.w3.org/wiki/SVG_Accessibility/Navigation 13:36:52 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 FE: To set focus on an element in CSS? 13:37:32 ABR: More to say whether something *could* achieve focus. 13:38:25 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 ... but most people just use 0, 1, -1, and let the browser handle exact order. 13:39:36 ... 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 ... I'd like to set up a meeting with Florian to talk about this. 13:40:23 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 DS: But not all roles *should* be focusable. Or maybe their children should/shouldn't be focusable. 13:41:45 ... So with focusable, the author could decide which node in the tree should be the focusable item 13:44:36 FE: Should roles be inherited? Otherwise, the markup could be quite verbose. 13:45:06 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 ... Can't find the link right now. 13:46:00 DS: That's a great idea. I didn't know that there was a draft. 13:46:34 JW: Another thing to distinguish is between the "point of regard" navigational focus point versus the text input focus point. 13:47:54 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 ... 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 ABR: A comparison is when you're reading a web page visually, you can scroll down without changing the focus. 13:50:33 JW: Basically, the idea is that you can interact with something that has focus. 13:51:31 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 ... In other cases, when you do navigate, both changes. 13:52:11 FE: But I think with interactive charts, it's often arbitrary which elements are interactive or not. 13:52:38 q+ 13:53:50 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 ABR: That sounds like a bad idea... 13:54:27 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 FE: But if you're navigating, and the focus identifier changes, you would expect that to also be the interactive element. 13:56:27 ... 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 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 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 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 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 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 FE: Because you might want to make landmarks, like headings, focusable without them being interactive 14:03:09 JW: And we can't reasonably expect the browser to always tell which elements are interactive. 14:03:29 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_ has joined #svg-a11y 14:05:12 yup 14:05:13 -Doug_Schepers 14:05:27 talk to you next week, or via email! :) 14:05:41 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 zakim, list participants 14:05:53 As of this point the attendees have been +1.703.978.aaaa, +1.609.906.aabb, Doug_Schepers, AmeliaBR 14:05:53 zakim, list participants 14:05:55 As of this point the attendees have been +1.703.978.aaaa, +1.609.906.aabb, Doug_Schepers, AmeliaBR 14:06:07 rrs, make minutes public 14:06:16 rrsAgent, make minutes public 14:06:16 I'm logging. I don't understand 'make minutes public', AmeliaBR. Try /msg RRSAgent help 14:06:36 rrsAgent, make logs public 14:06:52 rrsAgent, make minutes 14:06:52 I have made the request to generate http://www.w3.org/2015/04/17-svg-a11y-minutes.html AmeliaBR 14:13:50 -AmeliaBR 14:13:52 - +1.703.978.aaaa 14:14:05 - +1.609.906.aabb 14:14:06 WAI_SVGTF()9:00AM has ended 14:14:06 Attendees were +1.703.978.aaaa, +1.609.906.aabb, Doug_Schepers, AmeliaBR 16:31:12 Zakim has left #svg-a11y 16:44:40 chaals has joined #svg-a11y