See also: IRC log
<fesch> zakim: action-1584
https://www.w3.org/wiki/SVG_Accessibility/People_and_Issues
<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.
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
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
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]