ACTION-980: Describe/define managed aria related states: aria-setsize, aria-posinset, aria-level, focused, focusable with reference to section 5.5 bullet 1 of the UAIG.

moving to 1.1

Next step: David to take this up with Marco and report back in June.

[15:36:25] trackbot is looking up action-980.
[15:36:25] <trackbot> action-980 -- Cynthia Shelly to Define mappings for managed aria related states: aria-setsize, aria-posinset, arla-level, focused, focusable with reference to section 5.5 bullet 1 of the UAIG. -- due 2014-05-01 -- OPEN
[15:36:25] <trackbot> https://www.w3.org/WAI/PF/Group/track/actions/980
[15:38:09] clown (~clown@public.cloak) left IRC. (Request too long)
[15:38:14] clown (~clown@public.cloak) joined the channel.
[15:38:31] <clown> asdfasdf
[15:38:57] <clown> user agents must compute managed states VISIBLE/INVISIBLE, SHOWING/OFFSCREEN, etc. This typically is done in the same way as for ordinary elements that do not have WAI-ARIA attributes present. The FOCUSABLE/FOCUSED states may be affected by aria-activedescendant. See the rules in Controlling focus with aria-activedescendant.
[15:40:14] <clown> http://localhost/~clown/GitHub/aria/implementation/aria-implementation.html#mapping_state-property
[15:40:28] <joanie> CS: Is it adding more detail? Is that what it's asking for?
[15:40:35] <clown> http://rawgit.com/w3c/aria/master/implementation/aria-implementation.html#mapping_state-property
[15:40:46] <joanie> DB: I guess it's asking us to define how it's done so we come up with the same thing.
[15:42:06] <joanie> DB: We have an HTML version (accessibility guide)....
[15:42:15] <joanie> CS: Why do you think it belongs there and not in ARIA?
[15:42:22] <joanie> DB: The language might be similar.
[15:42:37] <joanie> CS: It makes sense to define it in HTML and reference it in ARIA.
[15:42:45] <joanie> CS: Add that to the issue.
[15:42:58] <joanie> CS: Should I do this or should David?
[15:43:05] <joanie> DB: Who is doing the HTML guide
[15:43:37] <joanie> JS: The editors for that guide are Jason Kiss, Alex Surkov, Steve Faulkner.
[15:43:40] <clown> http://rawgit.com/w3c/html-api-map/master/index.html
[15:43:53] <davidb> I think Alex could help with "This typically is done in the same way as for ordinary elements that do not have WAI-ARIA attributes present." for managed state stuff.
[15:44:12] <joanie> JS: I think (the above URL) is what you're talking about.
[15:45:00] <joanie> CS: What it is about... The first bullet has this text
[15:45:18] <cyns> this is too vague: "This typically is done in the same way as for ordinary elements that do not have ARIA "
[15:45:21] <davidb> (hmmm or maybe Marco)
[15:45:24] <cyns> need to define what is typically done
[15:45:35] <davidb> agreed
[15:45:49] <joanie> JS: So it's not specific to aria-setsize, posinset, level...?
[15:45:54] <joanie> CS: Those are the managed states
[15:46:00] <joanie> CS: The second piece is
[15:46:11] <cyns> 2nd piece is to define what ARIA managed states add/change
[15:46:52] <joanie> DB: This is an action?
[15:46:56] <joanie> JS: 980 is an action.
[15:47:02] <joanie> DB: We assign it maybe?
[15:47:11] <joanie> DB: I should talk to Alex and Marco first.

(from http://www.w3.org/2014/05/06-aapi-minutes.html#item06)

fixed spelling in action title

FF's own documentation on the managed states, including VISIBLE/OFFSCREEN, etc:
https://developer.mozilla.org/en-US/docs/Web/Accessibility/AT-APIs/MSAA/States

I found a comment about this action in the minutes of a face-to-face meeting where the action was created (07-Mar-2012):

"<MichaelC> issue: List managed states and define mappings for managed states".

The text to be fixed *is* vague. It doesn't list all the relevant states, uses "etc.", nor does it say how they are mapped:

"User agents MUST compute managed states VISIBLE/INVISIBLE, SHOWING/OFFSCREEN, etc. This typically is done in the same way as for ordinary elements that do not have WAI-ARIA attributes present. The FOCUSABLE/FOCUSED states may be affected by aria-activedescendant. See the rules in Controlling focus with aria-activedescendant."

NB: the states that are listed are AAPI states -- they look like MSAA states -- and not aria-* states. This makes it tricky to word in an AAPI neutral manner.

Note (to self): next step is to drive list of managed states. Pointers to existing desktop documentation. Ultimately get this documented for aria 1.1.

Updated action title.

Rich's email:
https://lists.w3.org/Archives/Public/public-pfwg/2015Feb/0054.html

Alex's response:
https://lists.w3.org/Archives/Public/public-pfwg/2015Feb/0060.html

My understanding is that the problems with the text currently are
- the list of managed states is incomplete,
- the names of the managed states are all from MSAA
- the notion of "managed state" is not clear.

Section 5.5.1, bullet 1 reads:

"User agents MUST compute managed states VISIBLE/INVISIBLE, SHOWING/OFFSCREEN, etc. This typically is done in the same way as for ordinary elements that do not have WAI-ARIA attributes present. The FOCUSABLE/FOCUSED states may be affected by aria-activedescendant. See the rules in Controlling focus with aria-activedescendant."

collecting some docs on states

MSAA states:
https://msdn.microsoft.com/en-us/library/ms697270.aspx

UIA mapping for MSAA states:
https://msdn.microsoft.com/en-us/library/ms788733(v=vs.110).aspx

IA2 states: http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/_accessible_states_8idl.html#addd157597a93d980dd833930198fb246

Gecko MSAA implementation
https://developer.mozilla.org/en-US/docs/Web/Accessibility/AT-APIs/MSAA/States

@cyns, yes that is the list. Although, I am not quite sure all of those are managed.

https://www.w3.org/2018/05/03-aria-minutes.html