Re: Firefox accessibility API mapping questions

What you say makes sense, but as long as it concerns to error handling it's
not a big deal from AT perspective which way we handle it. 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.

On Wed, Mar 25, 2015 at 3:56 PM, Joseph Scheuhammer <clown@alum.mit.edu>
wrote:

> On 2015-03-25 3:25 PM, Alexander Surkov wrote:
>
>> What is the point to put role="rowgroup" for the author if it doesn't
>> have accessibility mapping?
>>
>
> From an author's perspective, they may want to make the row group
> focusable, or have it aria-control something else, etc.  This is covered
> by what I wrote in my last email: "The only reasons for an accessible are
> if the rowgroup element is focusable, or has some other ARIA global
> attribute. "
>
> Otherwise, I don't see why an author would add a rowgroup.  But if they
> do, and it isn't focusable and doesn't have an aria-* attribute, then why
> would there need to be an accessible for it? The case is the same as the
> one you noted: "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."  Role rowgroup is "... a structural equivalent to the thead,
> tfoot, and tbody elements ..." [1].  Why not treat it the same way as you
> treat thead, etc?
>
> I *think* we agree, actually  :-)
>
> [1] http://w3c.github.io/aria/aria/aria.html#rowgroup
>
>
> --
> ;;;;joseph.
>
> 'Array(16).join("wat" - 1) + " Batman!"'
>            - G. Bernhardt -
>
>