See also: IRC log
<scribe> scribe: Brian
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
<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
<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
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
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: 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
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]