W3C

- DRAFT -

SVG Accessibility Task Force Teleconference
06 Apr 2016

See also: IRC log

Attendees

Present
LJWatson, Chaals, fesch, Brian, Rich, AmeliaBR
Regrets
Chair
fesch
Scribe
Brian

Contents


<scribe> scribe: Brian

around the table

a: Rich Core roles with the graphics we need the mappings from apple for

a: Rich check with Microsoft & UIA, wading through text ocmputation

<Rich> Rich: graphics module roles we need the mappings from apple for

<Rich> Rich: check with Microsoft & UIA, and wading through text ocmputation

Open Actions

<fesch> https://www.w3.org/WAI/PF/svg-a11y-tf/track/actions/overdue

<fesch> ACTION-2002

<trackbot> ACTION-2002 -- Amelia Bellamy-Royds to Draft new language for svg-aam. -- due 2016-03-30 -- OPEN

<trackbot> http://www.w3.org/WAI/PF/svg-a11y-tf/track/actions/2002

Amelia: No updates, couple more weeks for updates

<fesch> ACTION-2003

<trackbot> ACTION-2003 -- Richard Schwerdtfeger to Investigate how role=none interacts with other aria- attributes, in other aria specs. -- due 2016-03-01 -- OPEN

<trackbot> http://www.w3.org/WAI/PF/svg-a11y-tf/track/actions/2003

Rich: just started looking at this today
... what would casue role=none to be hidden. EG: tabindex

fesch: how do we treat elements with child title and role=presentation

ACTION-2004

<trackbot> ACTION-2004 -- Amelia Bellamy-Royds to Clean up rules for title & name description (github issue #137) -- due 2016-03-30 -- OPEN

<trackbot> http://www.w3.org/WAI/PF/svg-a11y-tf/track/actions/2004

AmeliaBR: some of this has been closed, some hasn't

fesch: any depend on SVG or is this just us?

AmeliaBR: some separaet edits that need to be made to SVG2

<fesch> ACTION-2015

<trackbot> ACTION-2015 -- Amelia Bellamy-Royds to Modify the svg2 spec. to require authors when useing <title> or <desc> to not leave them empty or with only white space. an author must -- due 2016-03-23 -- OPEN

<trackbot> http://www.w3.org/WAI/PF/svg-a11y-tf/track/actions/2015

<fesch> ACTION-2017

<trackbot> ACTION-2017 -- Fred Esch to Talk with michael cooper to determine where to place the svg accessibility authoring practices -- due 2016-03-16 -- OPEN

<trackbot> http://www.w3.org/WAI/PF/svg-a11y-tf/track/actions/2017

fesch: chaals cleaned up repository, if we stick with that we can removed this

<fesch> ACTION-2018

<trackbot> ACTION-2018 -- Charles McCathie Nevile to Make the scrapbook for authoring practices look like a w3c editors' draft. -- due 2016-03-23 -- OPEN

<trackbot> http://www.w3.org/WAI/PF/svg-a11y-tf/track/actions/2018

chaals: I beleive it's got the basic pieces done, if we update it I will add pieces so it looks more like something

<fesch> ACTION-2008

<trackbot> ACTION-2008 -- Doug Schepers to define authoring practices related to links -- due 2016-04-06 -- OPEN

<trackbot> http://www.w3.org/WAI/PF/svg-a11y-tf/track/actions/2008

fesch: Doug, can you put link authoring practices into chaals repo?

<chaals> authoring practices repo

Role mapping for SVG element

<AmeliaBR> https://lists.w3.org/Archives/Public/public-svg-a11y/2016Mar/0053.html

<fesch> HTML has different roles for the SVG element than SVG AAM

<fesch> That spec does not map <svg> to any existing ARIA role

<fesch> It does, however, map it to the relevant graphics-related roles in each API

<fesch> (or group if no appropriate role exists)

<fesch> vs

<fesch> group role

AmeliaBR: I noticed since the html spec defined the svg element
... they have mappings for the svg element, and they are differnet than our mappings
... the html aam has these mappings. It's more complicated, they have better mappings than us
... we need to investigate their mappings and consider if we want to adopt it
... we currently mpa SVG to group, which is not good. HTML spec has different mappings that are currently used on differnt platforms

Rich: the problem is where we're going, this doesn't make sense. It's hte opposite of where we want to go

fesch: is that because they're mapping to image?

Rich: UIA does nothing with SVG
... MSAA/UIA Express, not sure what to do with that
... ATK, not sure what Joanie's doing with that
... don't worry about it, I will coordinate with them

<chaals> [It would be nice to have some clearer information about what is really happening here - maybe a pointer to the two specs, or a summary of the proposed direction]

<fesch> https://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html#role-map-svg

<fesch> http://rawgit.com/w3c/aria/master/graphics-aam/graphics-aam.html#mapping_role_table

<AmeliaBR> ACTION Rich to Coordinate with HTML-AAM editors regarding correct mapping for <svg> element, in a way consistent with the new graphics role mappings

<trackbot> Created ACTION-2019 - Coordinate with html-aam editors regarding correct mapping for <svg> element, in a way consistent with the new graphics role mappings [on Richard Schwerdtfeger - due 2016-04-13].

<fesch> https://lists.w3.org/Archives/Public/public-svg-a11y/2016Apr/0002.html

chaals: Amelia, what's the email we're talking about?

<AmeliaBR> https://lists.w3.org/Archives/Public/public-svg-a11y/2016Mar/0053.html

AmeliaBR: It sounds like neither set of role mappings are ideal
... we need role mappings that indicate it's a graphic, but allwo it to have child content. I'm not sure which of these do

fesch: in HTML generally means no children

chaals: implemented that way in SVG. It'd be strange to say it means on thing in one place and another in another

fesch: for the first go around, we were reusing group becuse it exists. It's ugly, but it exists.

AmeliaBR: what we've got, and we don't waant it to stay. Rich mentioned joanie, and she updated webkit. I've had people come back and say "it sound's weird to say group"

fesch: rich may be better to address it. if APIs don't have an appropriate role, we're not gonna get them to put a new one in right away

AmeliaBR: I don't know what the answer is, but we need to have one answer in all three specs. Not three answers in three specs.

fesch: Do we need to talk about this more today, with the action

AmeliaBR: I don't think so, we need to do more investigation

Expectations for presentational element with title child

fesch: I think this topic also applies to desc

<fesch> https://lists.w3.org/Archives/Public/public-svg-a11y/2016Mar/0064.html

<fesch> https://lists.w3.org/Archives/Public/public-svg-a11y/2016Mar/0062.html

AmeliaBR: this was brought up by Joanie as she was trying to implement ... the way it's set in ARIA,

if an author gives role=presentation, none but also a global aria attribute, this is assumed to be an error and the role is ignored

fesch: tabindex too right

<chaals> q

AmeliaBR: Joanie wanted to know if the title element was something too that would cause role of presentation to be ignored
... Thsi is a wholy native SVG semantic, so this would be something we would need to define

chaals: this is a similarity that came up when looking at longdesc

<Rich> Rich: titles show tooltips so they have to be there

chaals: If you have a title, this seems reasonable. role=presentation to hide pieces of the image seems like a mistake

AmeliaBR: the one use case brough up is if you used the title for a tooltip, but are trying to minimize duplication for screen readers

chaals: I don't know how you'd do that, I see the point

AmeliaBR: maybe have a visible label and the tooltip
... not a great use case, but a possible one

chaals: I see the point. Inclined to suggest a better way as an answer to deal with that issue
... If you have a visual label that will be rendered anyway. Text is rendered remakably well. Inclined to say if in doubt, make it not presentation.

AmeliaBR: agree, if it's content being exposed to a user don't use presentation. Our answer to Joanie would be that, yes, title and desc should override role="none" and I will make the change

fesch: any other opinons? I'm also of the opinion that title and desc means you have meaning and is probably a mistake
... one use case is if you have a tiny item and use a tooltip

chaals: anyone on the call posing an objection?

AmeliaBR: do we want to bring this same issue up with the core group? The html title has the same issue

chaals: I would like to bring this up, and an action with WCAG

fesch: one clarrification, does that mean it's an error?

AmeliaBR: as in, should it show up as an error in a validator?

chaals: yes

AmeliaBR: I think so, so I think we need normative language. Authors should not use role=none/presentation when using title/desc

Rich: do that for desc? Desc is not visible

AmeliaBR: why would you put desc if you were not trying to make it accessible to screen reader users?

fesch: what if you make an ancestor not visible?

AmeliaBR: not visible is different than role=none

<chaals> proposed: RESOLUTION: Where an element has role=none or role=presentation and has a descendent title or desc element, user agents must ignore the role. Authors must not put role=none or role=presentation on elements that have descendent title or desc elements

Rich: tooltip is bad because there's a visual aspect to things. that's also consistent with what we're doing

<chaals> +1 to the proposal

<fesch> +1

rich: I'm sensing that when i modify the section in the aria spec i should modify this as well?

<AmeliaBR> +1 to proposal

Rich: I'll see where that is appropiate in the aria spec

AmeliaBR: Ok, so we can make the resolution for SVG at least because it is a native semantic

RESOLUTION: Where an element has role=none or role=presentation and has a descendent title or desc element, user agents must ignore the role. Authors must not put role=none or role=presentation on elements that have descendent title or desc elements

AmeliaBR: Rich, you're taking an action about how to work this into the ARIA spec

ACTION chaals to Follow up with WCAG

<trackbot> Created ACTION-2020 - Follow up with wcag [on Charles McCathie Nevile - due 2016-04-13].

<chaals> [sorry folks, have to go, as noted in email]

<chaals> action-2020?

<trackbot> action-2020 -- Charles McCathie Nevile to Follow up with wcag -- due 2016-04-13 -- OPEN

<trackbot> http://www.w3.org/WAI/PF/svg-a11y-tf/track/actions/2020

ACTION fesch to work role=none/presentation into svg spec

<trackbot> Created ACTION-2021 - Work role=none/presentation into svg spec [on Fred Esch - due 2016-04-13].

<AmeliaBR> action-2021

<trackbot> action-2021 -- Fred Esch to Work role=none/presentation into svg spec -- due 2016-04-13 -- OPEN

<trackbot> http://www.w3.org/WAI/PF/svg-a11y-tf/track/actions/2021

Difference between table and spec

AmeliaBR: we have ten minutes left, Fred do you have naything to say about testable statements?

fesch: I apologize if I'm confused, if you look at the agenda, will paste in stuff

<fesch> Expected results in the table for accessible name calculations for AXAPI

<fesch> shows AXDescription in the table where according to the formula in the core

<fesch> name spec AXTitleUIElement should be exposed. Joanie indicated that until

<fesch> she (linux) and apple see value in exposing the ATK_RELATION_LABELLED_BY

<fesch> relationship, that will use AXDescription without the labelledby

<fesch> relationship for SVG. Joanie suggested that the spec not be changed, to

<fesch> allow future use, but for CR exit criteria we should focus on AXDescription

<fesch> only. Since that is what she and apple do and I cannot think of a useful

<fesch> reason for them to change, I express the actual expected results in the

<fesch> table. (Please note, I may have bungled the explanation/properties

<fesch> involved, but we do have a difference between the spec and tests - Joanie

<fesch> may be able to attend our meeting to explain if needed). This will be a

<fesch> discussion topic at our next SVG a11y meeting.

<fesch> When Joanie pointed out the discrepancy between implementation and spec, I

<fesch> asked Rich to file a bug (which he did). If we agree to Joanie's and

<fesch> apple's point of view, then Rich will have to close the bug I asked him to

<fesch> file (sorry Rich).

<fesch> Automated Testing for 2 platforms

<fesch> Joanie has written about 200 SVG accessibility tests into webkit's

<fesch> regression testing. I think we should use these tests as part of CR

<fesch> testing. This will be a discussion topic at our next SVG a11y meeting.

fesch: for Apple they just use AXDescription, and I think Joanie does the ATK relationby
... I think there is a disconnect between what they're saying and what apple has implemented
... first thing, need to make sure I know what the situtation is. What do we need to do to have the name calculation reflect what happens in SVG with Apple.

Rich: We can rewrite the steps, but it sounds like you want to change core to handle this.
... haven't looked in detail at the AccName computation

<Rich> http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html

Rich: this is the base for all languages. Now, we can override it. You're saying there's a bug, even for html, correct?

fesch: I don't know that's true. I'm going off what Joanie say about exposing an extra relationship

AmeliaBR: From what I understood, they expose the relationship on form elements only

fesch: isn't this AXAPI
... ATK ATSPI is what joanie uses on linux?

Rich: Correct. They don't expose the aria relationships for labelling in Mac

<Rich> http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html#accessible-name-and-description-mapping

Rich: They don't have a ...

fesch: AXTitle was the issue. They use AXDescription

Rich: Unless you have one label it always points to a description

AmeliaBR: the more general issue is should we force new behavior on APIs when they're already happy with a simpler model?

Rich: I think we should fit into the general scheme they're using

fesch: I think what Joanie told me they do is that, if you have one or many, it comes out as AXDescription and there is no link back

Rich: did htey check the AXTitle? That's different than this table

fesch: that's what i'm saying. They only use AXTitle when they use a widget or form elements

<fesch> a/AXUIElement/AXUIElement

Rich: what happens if they have a role="text" and aria-labelledby and it's inside a form?

AmeliaBR: nothign in this conversation makes me think we need special rules for SVG
... this is really a core discussion for the API call

fesch: I want this group to be aware that I tried to sync the testable statements to what Joanie said was implemented.
... If you don't want me to do that, this is something we can discuss

AmeliaBR: I think it makes sense for now to note this as an issue, in order for tests to test the SVG aspects
... as long as we clearly document the choices we've made, just so we can update it based on the decisions are made for the core spec

fesch: I just wanted to log this so people are aware
... we've run out of time, any other topics?

Rich: I think we need to sit down with joanie and see what state it's in, for the name and description

fesch: I can bring in the list, it may be just my misunderstanding of what she's saying
... On list we'll figure it out with Joanie. It's bigger than SVG, but we'll figure it out and put it on the ARIA list

Summary of Action Items

Summary of Resolutions

  1. Where an element has role=none or role=presentation and has a descendent title or desc element, user agents must ignore the role. Authors must not put role=none or role=presentation on elements that have descendent title or desc elements
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/04/06 19:03:42 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/udaated/updated/
Succeeded: s/fesch/rich/
Succeeded: s/code/expose/
Succeeded: s/AXTitle/AXUIElement/
Found Scribe: Brian
Inferring ScribeNick: Brian
Present: LJWatson Chaals fesch Brian Rich AmeliaBR
Found Date: 06 Apr 2016
Guessing minutes URL: http://www.w3.org/2016/04/06-svg-a11y-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]