[aapi] Minutes: UAI TF Meeting Tue 21 October 2014

Link: http://www.w3.org/2014/10/21-aapi-minutes.html

Plain text follows:

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

           Protocols and Formats Working Group Teleconference
                              21 Oct 2014

   See also: [2]IRC log

      [2] http://www.w3.org/2014/10/21-aapi-irc

Attendees

   Present
          Cynthia_Shelly, David_Bolter, Bryan_Garaventa,
          Joseph_Scheuhammer, Joanmarie_Diggs,
          Richard_Schwerdtfeger

   Regrets
   Chair
          Joseph_Scheuhammer

   Scribe
          Joanmarie_Diggs

Contents

     * [3]Topics
         1. [4]ACTION-980: (David) Define mappings for managed
            aria related states with reference to section 5.5,
            item 1.
         2. [5]ACTION-1185: (Cynthia) Look into UIA Express and
            UIA mappings for role=heading to check for heading
            paragraph style.
     * [6]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 21 October 2014

   <clown> agenda: this

   <scribe> scribe: Joanmarie_Diggs

   <clown> [7]https://github.com/w3c/aria

      [7] https://github.com/w3c/aria

   <clown> git pull —rebase

ACTION-980: (David) Define mappings for managed aria related states
with reference to section 5.5, item 1.

   <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> [8]https://www.w3.org/WAI/PF/Group/track/actions/980

      [8] 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>
   [9]http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#dfn
   -managed-state

      [9]
http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#dfn-managed-state

   JS: The above is the definition for managed states.

   <clown>
   [10]http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ma
   pping_state-property

     [10]
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>
   [11]https://developer.mozilla.org/en-US/docs/Web/Accessibility/
   AT-APIs/MSAA/States

     [11]
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.

ACTION-1185: (Cynthia) Look into UIA Express and UIA mappings for
role=heading to check for heading paragraph style.

   <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>
   [12]https://www.w3.org/WAI/PF/Group/track/actions/1185

     [12] 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>
   [13]http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ro
   le-map-heading

     [13]
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>
   [14]http://rawgit.com/w3c/aria/master/aria/aria.html#heading

     [14] 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>
   [15]http://lists.w3.org/Archives/Public/w3c-wai-ig/2014JulSep/0
   040.html

     [15]
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.

Summary of Action Items

   [End of minutes]

Received on Tuesday, 21 October 2014 20:22:33 UTC