Re: Firefox accessibility API mapping questions

Hi, Rich. I missed how 4 follows from 1, 2, 3 because row count and row
indexes seem unrelated with row groups, at least I don't see a reason why
they should be.
Thanks.
Alex.

On Tue, Mar 24, 2015 at 3:50 PM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:

> Alex,
>
> This is in response to your first bullet on rowgroup after today's #aapi
> discussion:
>
> 1. The group has determined that the aria-rowcount needs to be indicative
> of the total number of rows in the entire table or grid.
> 2. The aria-rowindex is indicative of the index of the row within the
> entire set of rows for the entire grid or table
> 3. Due to 1 and 2 rowgroups have no impact on the values for aria-rowcount
> and aria-rowindex
> 4. So, a rowgroup will have no impact on context with respect to row
> count. So, if it is focusable (has a tabindex attribute) or it has an ARIA
> global attribute applied we will give a role of "group" for MSAA based
> platforms or UIA, ATK/ATSPI will make it a ROLE_PANEL otherwise it will not
> be mapped.
>
> Rich
>
>
> Rich Schwerdtfeger
>
> [image: Inactive hide details for Alexander Surkov ---02/17/2015 04:13:28
> PM---Hi, Rich. 1. I only see one use case for role="rowgroup"]Alexander
> Surkov ---02/17/2015 04:13:28 PM---Hi, Rich. 1. I only see one use case for
> role="rowgroup" is to break rows into
>
> From: Alexander Surkov <surkov.alexander@gmail.com>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: David Bolter <dbolter@mozilla.com>, PF <public-pfwg@w3.org>
> Date: 02/17/2015 04:13 PM
> Subject: 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*
> <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* <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*
>    <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
>
>
>