Re: Firefox accessibility API mapping questions

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



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

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


  Rich

  Rich Schwerdtfeger