Re: HTML focusable areas feedback

> On Jul 26, 2014, at 12:34, Steve Faulkner <faulkner.steve@gmail.com> wrote:
> 
> Hi James
> 
> Sent from my Chorizone 
> 
>> On 26 Jul 2014, at 20:38, "james.nurthen@oracle.com" <james.nurthen@oracle.com> wrote:
>> 
>> 
>> 
>>> On Jul 26, 2014, at 10:43, Steve Faulkner <faulkner.steve@gmail.com> wrote:
>>> 
>>> Hi James 
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 26 Jul 2014, at 18:59, James Nurthen <james.nurthen@oracle.com> wrote:
>>>> 
>>>> If these are focusable by default (as is currently the case in FF) then 2 additional things need to happen
>>>> 1) it MUST be possible for a web developer to reverse this behaviour. The current FF behaviour is causing us issues in some combobox implementations and needs to be resolved. I would suggest allowing tabindex=-1 to ensure the area is never focusable. This does not work in the current FF implementation
>>> 
>>> Does using tabindex=-1 resolve the issue in FF?
>> 
>> No. FF still focuses it.
> 
> Suggest that is a bug, best to file one against FF

I agree. Unfortunately I'm on vacation for 3 weeks and have no laptop with me. I'll try to remember to do it when I get back. 

As you can imagine getting an extra focusable area in a widget plays havoc with widgets which use either roaming tabindex or aria-activedescendent to manage their focus. 


> 
>>> 
>>>> 2) An accessible name and role needs to be provided for this region so AT can determine what to speak when it gets focus.
>>> 
>>> Being scrollable, I would suggest, is a property not a role.
>> 
>> What role would you give it then?
> 
> If the element already has a role there is no need. 
> <section> for example has a default role of region.
> If not would depend on what the element content was, I think.

Most of the time I imagine the element would be a div. I seem to recall the mapping for this differ vastly depending on the platform. 

> 
>> 
>>> 
>>> 
>>>> 
>>>> Regards,
>>>> James
>>>>

Received on Saturday, 26 July 2014 20:21:16 UTC