Re: Firefox accessibility API mapping questions

Alex, while In appreciate the performance issue there is value in being
consistent across platforms and not mapping also removes an accessible from
the tree.


Rich Schwerdtfeger



From:	Alexander Surkov <surkov.alexander@gmail.com>
To:	Joseph Scheuhammer <clown@alum.mit.edu>
Cc:	Richard Schwerdtfeger/Austin/IBM@IBMUS, David Bolter
            <dbolter@mozilla.com>, PF <public-pfwg@w3.org>
Date:	03/26/2015 09:06 AM
Subject:	Re: Firefox accessibility API mapping questions





On Thu, Mar 26, 2015 at 9:41 AM, Joseph Scheuhammer <clown@alum.mit.edu>
wrote:
  On 2015-03-26 9:03 AM, Alexander Surkov wrote:
   What you say makes sense, ...

  Wonders never cease :-)

that's rather a rule than wonders I would say :)


   ... but as long as it concerns to error handling it's not a big deal
   from AT perspective which way we handle it.  ...

  That's not what I'm told by one AT developer.  Having to deal with empty,
  non-signficant rowgroup accessibles is a pain, apparently. It clutters
  the accessibility tree with useless stuff.

They may get an accessible for role="rowgroup" (when it's focusable) so
they have to know how to deal with it. In case of ATK and IAccessible2
there is accessible table interface that is supposed to provide seamless
access to data regardless of row groups presence.


   The implementation matters though. In Firefox we used to treat @role
   attribute presence as indication of the accessible (except
   role="presentation"), thus the requirement to not create an accessible
   sounds like extra work for me.

  So, always creating an accessible for rowgroup is because of
  implementation efficiency?  However, I'm a little confused since that is
  inconsistent with: "Firefox doesn't expose group accessibles for HTML
  tables like thead, tfoot or tbody in general ...".  Does FF *always*
  provide an accessible for "thead"?  Or only when it is focusable, etc.?

If we see thead and etc then we do nothing and just get into fallback
procedure (checking whether node is focusable etc). If we see @role
attribute then we create an accessible. We could add a check for "rowgroup"
like we do for role="presentation", but it sounds like minor thing that
requires some work on our side, at least until that AT developer reveal
more data. On the other hand, we tend to respect the author intent (and
errors :) ), if he puts role="foo" then we expose an accessible for the
node, that'd be reasonable to do so for rowgroup role I think.


  Thanks for the disussion and clarifications.

thanks to you



  --
  ;;;;joseph.

  'Array(16).join("wat" - 1) + " Batman!"'
             - G. Bernhardt -