Re: W3C User Agent Teleconference for 3 November 2005

> An alternative would be to define, in format specifications, that 
> anything that has intereaction behaviour (an event listener, or a 
> default interactivity), should be focusable.
Isn't there a problem that an event handler may be on the container for 
something so that it can listen to the event on any descendant? It just 
uses event.target in the script to see where the event happened. We also 
have the problem that there are no descriptions for XML event handlers, 
so even if a user can get there, how will they know what these 
programmatic event names mean?

To help the discussion, here are 3 kinds of navigation we need to 
support in every kind of web content:

1. Simple controls are in tab order
- Examples: checkbox, slider

2. Container controls group focusable children
- Examples: trees, lists, radio groups, spreadsheets
- The last focused child is in the tab order
- Other children can be focused via the pointer
- Key navigation managed by the container widget (often arrows)

3. Non-interactive content won’t take input
- Examples: progress meter, alerts, doc structural elements
- Click to focus skips, goes up parent chain for focus
- On screen keyboards don’t list them as choices
- Screen readers skip them in navigation order
- Voice input skips them during “say what you see” vocab buildup

Received on Wednesday, 16 November 2005 18:07:40 UTC