See also: IRC log
<trackbot> Date: 28 April 2014
<richardschwerdtfeger> meeting: W3C WAI-PF ARIA Caucus
<Birkir> the 703 number is me, Birkir Gunnarsson
<MichaelC> scribe: LJWatson
<scribe> scribe: Léonie Watson
scribenick LJWatson
<richardschwerdtfeger> http://lists.w3.org/Archives/Public/public-pfwg/2014Apr/0156.html
RS: Referencing core mappings from HTML and SVG. Linking to mappings is annoying for devs.
<MichaelC> Issues raised on HTML AAPI mapping during editors´ call:
<MichaelC> minimize duplication of effort
<MichaelC> HTML elements don´t all have a corresponding ARIA role
<MichaelC> implicit ARIA semantics important in some case, so need to still document
<MichaelC> won´t fill all HTML elements with ARIA in ARIA 1.1
<MichaelC> but it´s a goal to do that eventually
<MichaelC> valuable to single-source this, have to sort out how to do that between two WGs
<MichaelC> can we drop the HTML 4 column?
<MichaelC> and HTML 5 needs to be HTML 5.1
<MichaelC> want views of the document(s) that don´t force developers to follow links back and forth
JC: In the guide you need to map to the platform specific role?
RS: Yes. Want to pull in the mapping from the core spec, instead of link to it.
JC: One spec with all ARIA and UA stuff combined?
RS: Core implementation guide with ARIA, then HTML and SVG specific guides that would reference the core.
JC: Why have multiple at all?
RS: Multiple?
JC: List all mappings in a single document.
RS: We're trying not to have a
huge spec, where we have to duplicate mappings for different
platforms.
... So if checkbox is defined for HTML, no need to duplicate
the info for SVG.
JC: There is no checkbox role in
SVG.
... So one map for all roles makes sense.
RS: Yes, but peole want to pull that information out of the core into the platform specific docs, instead of linking back to the core.
MK: We just want to maintain the information in a single place and reuse it?
RS: Yes.
JS: One quetion is whether we replicate the information. Also want to avoid repeating any aspect of the definition.
JC: If we include all the guides
in the specs, it would make the specs huge, but we'd also need
to revision them each time something changed.
... Feels like anti-modularisation.
RS: I see it has picking up info automatically from the core. Programmatically.
JS: At time of publication, or at time someone reads it?
MK: Specs have to be specs.
RS: We'd need to programmatically reference the core spec.
JC: Separate platform implementations should be separate.
RS: People are saying they don't want to link out to separate docs.
MK: We haven't had the opportunity to experience a modularised spec yet. Should wait to see if it's an issue or not.
RS: I'm just responding to feedback on the call last Wednesday, via Cynthia.
JS: It's less work to start creating modules with links. If it is a problem, we can address it then.
RS: Happy to do that.
... Means we'll have to have references to the table rows,
which we don't currently have.
MC: Yes. Haven't looked at source to see if present already.
JC: If this is a request we think will benefit a lot of people we should think about it, but if it makes a lot of work and adds to the process, for the sake of comments from one source it probably isn't worth it.
MC: We can raise this during a public review.
JC: Don't think we need to publish language specific to ARIA mappings.
RS: The suggestion was to pull in the references.
JC: Yes, but that will still result in references in two places.
RS: We'll leave it at using links for now.
<jcraig> agenda
RESOLUTION: We will reference the core API mapping specification using links.
JS: WAI-ARIA User Agent Implementation Guidelines: X module
RS: Will need to run this by the WG.
JS: May need to include a number also.
RS: Is this something the co-ordination group wants?
JS: Judy's concern is that WAI is part of the name.
MC: It's the trademark issue.
RS: We want to go with this?
<Birkir> It´s "WAI" long.
JS: The current HTML and SVG docs aren't all ARIA. Perhaps the ARIA stuff should be split out and maintained here?
RS: Don't think it should be broken up.
JS: That changes things, because there is no set.
MK: The HTML doc is all ARIA?
RS: Example - if you have a node added/removed, that's an event regardless of ARIA or not.
MK: So everything is related to accessibility, but not nescessarily ARIA?
RS: Could use WAI User Agent Implementation Guide: X module?
JS: Do we throw everything together, or separate it out? If we throw it together I withdraw my suggestion.
MC: Want to have parallelism between our approach on different specs.
RS: SVG is trying to recharter. Two shifting sands, so we need to be quick about this.
MC: The WG could indicate in their charter that the TF/deliverable will be renamed, that should mean they're not held up.
<richardschwerdtfeger> https://www.w3.org/WAI/PF/Group/track/issues/638
RS: For divs and spans, do we want a particular container role?
MK: Is there an IA2 mapping?
RS: Not sure if the MSAA equivalent would be desireable.
JC: Sometimes mapped to xgroup on the Mac, but that's not the same as the group role.
<jcraig> issue-638?
<trackbot> issue-638 -- Generic container roles for things like div/span… -- open
<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/638
<richardschwerdtfeger> http://lists.w3.org/Archives/Public/public-pfwg/2014Apr/0156.html
MK: There are actions we wanted to complete on this before we go further.
<richardschwerdtfeger> https://svgwg.org/svg2-draft/struct.html#implicit-aria-semantics
MK: AT don't reveal it unless it has a label, so it's like role="none". Would having a label give it a different role?
<richardschwerdtfeger> presentation role provided no associated ‘title’ element, ‘desc’ element, ‘aria-label’ attribute, ‘aria-labelledby’ attribute, or ‘aria-describedby’ attribute; otherwise, group role
MK: Conditional mapping?
RS: Yes.
JC: Shouldn't rely on having a description if there is no label.
RS: if label is provided... use group.
JC: Heuristics should be more simple. EG. Should be presentation unless it has a label.
RS: If you ref something presentational with ARIA, that protects against that.
JC: Referencing something
presentational/unfocuable etc. would be an author error.
... When mapping an element, shouldn't have to look at rest of
DOM to find out if it's been referenced.
... Would be a performance hit.
RS: Yes.
<jcraig> we can hear you rich
<jcraig> zalim, who is on the phone?
MK: James did you suggest that elements without labels shouldn't have descriptions?
<Birkir> 703 is actually Birkir Gunnarsson, SAilesh used to be part of the group, we call in from the same office #
MK: Can see times when you'd want a description on a presentational element.
JC: You wouldn't map an element with role="presentation" referenced by aria-describedby.
RS: Looking at 5.12 of the UAIG.
<richardschwerdtfeger> http://www.w3.org/WAI/PF/aria-implementation/#include_elements
RS: Need to be clear on this.
MK: Remember these sections got
complicated.
... That list in 5.12 is irrelevant, if it's already
excluded.
RS: So need an exception in SVG for aria-labelledby?
MK: Either need to make SVG consistent, or it breaks for everybody.
RS: Do think if have label, or title/desc element, we allow it.
MK: So role="presentation" would
be put in tree, but what? Generic role?
... So if new role, don't have to change stuff about
presentation?
RS: Have to make exception for
aria-labelledby.
... If role="none", have to have label for it to be mapped.
MK: What about the lement being referred to by aria-labelledby?
RS: If div with aria-labelledby
on, then the element assumes a role of group - to be consistent
with SVG.
... If no label, the element has presentation role and is not
in tree.
MK: Talk was of a new generic
role, not group.
... In HTML wuldn't want div to be mapped to group.
JC: No, group implies more semantics than div.#
RS: Do we want a new role?
JC: Yes, so we can have 1 to 1
mappings with every language.
... Want to get something into 1.1 first.
MK: Suggestion was that none be a synonym for presentation.
JC: In SVG spec none means no mapping.
MK: Did we put none as a presentation synonym?
JC: We agreed to it.
... All mapped to none are considered not rendered.
... Things like cursor etc.
RS: Yes.
... These are host language semantics.
JC: Yes.
... For all listed as none, they're not rendered (with couple
of excptions).
RS: Think ARIA none would be fine for those.
JC: No, these are not in the tree/rendered at all.
RS: If role="none on img, there is no mapping.
JC: These roles are not rendered at all, like script or style tags for example.
RS: Not the same as SGML docs.
MK: Are we talking SVG specific as part of 638?
JC: This is more editorial.
... We could map these to our new generic role by default.
circle, rect etc. are represented in the acc tree.
RS: Don't have to call it group.
JC: Llike xgroup - generic
container.
... Perhaps role=generic ?
RS: role=container
JC: Tempting.
... Difference between div and span.
... Sometimes map span if different style properties.
MK: Don't want an AT to communicate the role, just want the acc tree to have a rperesentation of the element.
MG: The role itself carries 0 meaning to the end user, correct?
JC: A non-specific meaning.
MK: The aim is to make the element neutral like a div.
JC: Right, no role description.
LW: Would call div and g containers, but not span.
JC: A span with display:block; is equivalent to a div.
MK: role=generic feels like an
abstract role, except it appear sin the tree.
... Is that a problem? Authors can't use abstract roles.
MC: Neither are UA.
RS: We want to chew on this for a week?
JC: Need to think about any
implementation considerations of what we're proposing.
... Need to consider implimentation factors.
RS: Next week someone from the MS Office team is joining us.
<jcraig> action-1424?
<trackbot> action-1424 -- James Craig to Propose spec text for generic/general/??? role (computed role of html:div, html:span, svg:g, etc) and clearly explain explicit usage of this role is not common, and clearly explain relationship to group and none role. -- due 2014-04-21 -- OPEN
<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1424
JC: Will come up with something for us to consider, other than role="none".