Re: Today's call and Keyboard Navigation

Well, we could say it's complicated but still worth a go!

Dividing the SC up into parts will at least give some automatisable things.

I was  counting  the button element as a form element, but yes it should be
made explicit.

Tabindex : tabindex="-1" removes the element from the stack so I suppose
you are considering the dynamic changes to tabindex (as mentioned later)?
Would we agree that on page load everything that can be mouse focussed must
be tabbable?  That woud seem a fair be to me.

Yes there are non implementable events, but if we can not even get to an
element with the keyboard, and yet that element indicates mouse listeners,
etc... then I think we have failure of the SC

Actually, we should even include CSS  "hover" and "focus" here too, don't
you think?

On 23 October 2014 15:44, Aurélien Levy <aurelien.levy@temesis.com> wrote:

> Hi John,
>
>  Dear All,
>>
>> == Description ==
>> That the navigation of the page be possible without using a pointer
>> (mouse or trackpad); that is, with the keyboard we can traverse, activate
>> and manipulate the same elements in the page as with the pointer.
>>
> it isn't necessary true because it's not necessary the same elements you
> can have one working with keyboard and one with pointer.
>
>  Traditionally this SC is not tested for automatically, but manually.
>> However a well devised automatic non-exhaustive test is still possible,
>> based on the following reasoning.
>>
>> * True links and true form elements can recieve keyboard focus.
>>
> don't forget button element
>
>> * Any other element in the DOM with which we can interact will have an
>> appropriate event listener.
>> * If this element is not a form element or a link, it must have a
>> tabindex attribut that is zero or greater.
>>
> or a tabindex -1
>
>> * If it has listeners that refer to the mouse only, they must be doubled
>> by their keyboard counterparts.
>>
> it's not that simple, some events do not have counterparts "ondoubleclick"
> "onscroll" for example, as already said you can have a different element
> with same action who can be used with keyboard and if your element is a
> link, button or form element you don't have to check that because it's
> natively keyboard accessible
>
>>
>> [http://www.w3schools.com/jsref/dom_obj_event.asp List of event
>> listeners]
>>
>> We are thus looking for:
>> * elements which have event listeners of any kind, but which are not "a"
>> tags or "input" tags and which do not have tabindex set to 0 or greater.
>> * elements which have mouse related event listeners but not keyboard
>> related event listeners.
>> * True links with tabindex set to -1
>> * Inputs with tabindex set to -1
>>
> it's not necessary a fail if the tabindex is removed after some actions in
> the page (for example with  aria tabpanel design pattern you can have
> inactive links)
>
>>
>> If we find such things, the test will fail.
>>
> So basically nothing can be totally automated without generating false
> positive or false negative
>
> --
> Aurélien Levy
> ----
> Temesis
>
>
>