See also: IRC log
<trackbot> Date: 21 October 2014
<clown> agenda: this
<scribe> scribe: Joanmarie_Diggs
<clown> https://github.com/w3c/aria
<clown> git pull —rebase
<clown> action-980?
<trackbot> action-980 -- David Bolter to Define mappings for managed aria related states: aria-setsize, aria-posinset, aria-level, focused, focusable with reference to section 5.5 bullet 1 of the UAIG. -- due 2014-09-23 -- OPEN
<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/980
JS: This came up as due again, action-980. It's David's action. I looked at it to remind myself what it was.
<clown> "issue: List managed states and define mappings for managed states".
JS: I found that the action was created back in March 2012 at a face-to-face. In those minutes the above quote was found.
RS: I remember that. It was because this was going to be a core specification for HTML, SVG, etc. and these things need to be there as well.
DB: Is making this core going to make everything more heavy-weight?
RS: I don't know if there's other
things we need to consider, but managing this stuff for HTML5,
SVG, etc. is important. And we don't want to duplicate
it.
... The HTML and SVG mapping should be rather small.
DB: I don't know what the "etc."
is at the end of the list of sample states.
... Perhaps we can remove the "etc." for now?
... We have a definition in the guide for managed states.
JS: And in that guide it mentions selection as one of the managed states.
DB: This issue could probably
become large-ish.
... In the sense that all the prose would not go into this
bullet.
JS: Agreed, the mapping is not
going to go into this bullet point. That might become a second
section.
... (Reading from document). This sounds like states which
happen independent of ARIA.
DB: This bullet seems to assume
that HTML sans ARIA, user agents figure out what to expose. And
we're calling that managed states.
... And I think what's being said is that we also need to
mention this / explain this for ARIA.
... I think that managed states would belong in HTML or
somewhere. Then in ARIA we'd link back to that doc and mention
any ARIA-specific needs.
<clown> http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#dfn-managed-state
JS: The above is the definition for managed states.
<clown> http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#mapping_state-property
<davidb> (group takes a moment to complain about visibility state mess)
(Discussion about platforms at their states, e.g. VISIBLE, etc.)
CS: In UIA there are also equivalents, but I'd have to look up their exact names.
JS: The trick is finding the right words, avoiding platform-specific names.
CS: We can use prose to describe them.
DB: First step might be to list
all the states we think are managed.
... Then add links to the platform-specific accessibility
APIs.
... And then determine where exactly to put it.
JS: My inclination is to put that
paragraph right here (in the core aam).
... I agree with Cynthia that it has to indicate we're taking
about accessibility API states without using any platform's
specific terminology.
JD: +1 to what Joseph and Cynthia said.
JS: So in summary, step 1 is to list what we think those states are.
DB: I can be the driver if you'd like.
RS: So this is going into core?
JS: David suggested it might need to go somewhere else.
DB: My concern is capturing it first.
RS: We'll need this for SVG somehow.
<clown> https://developer.mozilla.org/en-US/docs/Web/Accessibility/AT-APIs/MSAA/States
JS: Conclusion, David will drive it, starting with the first step (listing the states).
RS: We were trying to synchronize
ARIA 1.1 with HTML 5 which was going to be 2016. But they
changed that date.
... What didn't get implemented will be added in a 5.1.
... Now I'm not sure how we're going to synchronize this. I
have been aiming for 2016, but earlier if possible.
... Earlier would mean less in 1.1 and postponing some things
for ARIA 2.0.
DB: For our purposes, I'd like to target January 27th for getting this action done.
RS: That's fine as it only
impacts the browsers directly, and will probably be documenting
of what is already being done by them.
... This will be helpful for SVG though.
<clown> action-1185?
<trackbot> action-1185 -- Joseph Scheuhammer to Look into UIA Express and UIA mappings for role=heading to check for heading paragraph style. -- due 2014-09-09 -- OPEN
<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1185
JS: This is now my action,
Cynthia did the work. But I have questions for her.
... (Reads from text)
... So you want me to stick in the mapping for UIA the actual
code?
CS: You can use the identifier. The tool I have shows the number.
<bgaraventa1979> +q
<clown> http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-heading
JS: (Quotes from the above)
JS states his understanding of the change, Cynthia confirms.
CS: The style pattern has the ID.
JS: I will try to do this by next week.
BG: Is aria-level required?
JS: aria-level is supported but not required
BG: Should aria-level should be a MUST for role="heading"
JD: Should it?
BG: I'd assume so.
... This came up at a discussion earlier this year. Steve
Faulkner pointed out that it wasn't required.
CS: Do you have any recollection, Rich, of why heading doesn't have a required level?
RS: That really doesn't make sense.
DB: Is it perhaps implicit based on nesting?
<clown> http://rawgit.com/w3c/aria/master/aria/aria.html#heading
RS: I would make that an issue (a
spec issue).
... People will do it anyway, but I think it should be
required.
DB: It wouldn't surprise me if Gecko calculates it if the level is not specified.
RS: One of the problems with
headings in general is that it's not a section. It just sits
out there. So calculating it is difficult.
... Would you prefer it be explicit or calculated?
JS: Explicit makes it a MUST.
DB: I wouldn't want to discourage people from using heading.
JS: aria-level doesn't even have a default value.
JS and DB: I don't think we have tests for this.
DB: I'll ask Alex Surkov.
JS: This doesn't change my edit
because the actual mapping says that the level comes from the
aria-level attribute.
... Bryan, would you like to raise an issue with the spec?
BG: I'll do so.
DB: Alex's response: If I recall correctly we don't calculate it. I'm not sure why it should be required. Some default value can be provided.
<davidb> DB: tend to agree
CS: Having a default as a repair mechanism probably makes sense. But I think it should be required.
<clown> davidb, can you ask alex what the default value is?
CS: What would the default be? 1? You can only have one of those.
<bgaraventa1979> http://lists.w3.org/Archives/Public/w3c-wai-ig/2014JulSep/0040.html
BG: The above is the link to the thread I was refering to earlier.
<davidb> clown, alex says '1'
<clown> davidb, thank alex for that.
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 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: joanie Found Scribe: Joanmarie_Diggs Present: Cynthia_Shelly David_Bolter Bryan_Garaventa Joseph_Scheuhammer Joanmarie_Diggs Richard_Schwerdtfeger Found Date: 21 Oct 2014 Guessing minutes URL: http://www.w3.org/2014/10/21-aapi-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]