Re: Firefox accessibility API mapping questions

Hi, Rich.

1. I only see one use case for role="rowgroup" is to break rows into
groups, each groups is a separate set and position inside it and set size
are calculated independently.

On the implementation note I think it's much easier to map @role to
something meaningful (role="presentation" has quite special handling in
Firefox in contrast to other roles).

On the author note, If the author puts this role then it puts it for
something (otherwise he could skip it at all), so if we ignored it then it
wouldn't be probably much right. Firefox doesn't expose group accessibles
for HTML tables like thead, tfoot or tbody in general, but as long as the
author makes those elements focusable (what happens in the wild) we create
an accessible for them. In case of HTML table based grids, those focusable
elements expose role="rowgroup" what "legalize" their presence for AT.

2. This is a whole bunch of stuff that makes sense to deal separately with.

2.1 (level, position in set, set size). Cynthia recently raised a question
about level calculation [1] and I said that UAIG would need to describe
allowed widget structure for that. Having all possible structures defined
we can make level, posinset and size definitions rather straight forward.
If you support this idea then I'm happy to help.

2.2. focused/focusable - these concepts reflects the user focus:
a) any DOM focusable DOM element/DOM document should expose 'focusable'
state, if DOM element or document has DOM focus then it should have
'focused' state.
b) every item of DOM focusable widget should expose 'focusable' state, if
the widget is DOM focused then current item should expose 'focused' state.

We may have c) for aria-activedesdendant case but it should be covered by
b) if we defined those widget structures.

2.3 offscreen state has to be exposed on the accessible what is out of
viewport and what can be made visible by the user. Scrolled off, in
background tab, elements should expose offscreen state. Note, moved out of
the screen elements also expose offscreen state but this is rather
exception and has historical reasons. Invisible state is for something
invisible and that cannot be made visible by the user. I don't think we use
this state much in Firefox, I think we expose it for accessible that is
shutting down. Otherwise it could be useful if we exposed accessibles for
hidden content that is referred by other content, for example, if
aria-labelledby pointed to hidden element.

Hope that helps.
Thanks!
Alex.


[1] https://lists.w3.org/Archives/Public/public-pfwg/2015Feb/0026.html

On Tue, Feb 17, 2015 at 3:32 PM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:

> Hi Alex,
>
> I am in the Accessibility API mapping meeting and we need answers to 2
> questions:
>
> 1. Why does role="rowgroup" need to be mapped?
>
> MSAA and UIA Express map the string "rowgroup" into the ARIA role
> property. IA2 exposes it as ROLE_SYSTEM_GROUP. UIA exposes it as group
> which also means nothing. ATK/ATSPI does not map it and MacOSX also does
> not map it.
>
> The meaning of role="group" is now being re-defined in ARIA to have no
> meaning other than to be a structural container to be consistent with older
> versions of IE and Mac OSXX?
>
> 2. How are you computing managed properties for level, position in set,
> set size, focused, focusable, offscreen etc.
> See https://www.w3.org/WAI/PF/Group/track/actions/980
>
> See this section of the Core Accessibility API mapping spec. Item 1:
>
>
> *http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#statePropertyMappingGeneralRules*
> <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#statePropertyMappingGeneralRules>
>
> Rich
>
> Rich Schwerdtfeger
>