Accessibility Considerations for Design Patterns

[Greg Gay]

Hi Mike

Michael S Elledge wrote:

>> Optional form focus is a great usability feature for AT users, provided
>> it is used carefully, and is optional should a user decide not to want
>> it. When the primary content of a page is a form, and the user is
>> expecting a form, position the focus in the first field.
>>   
>
> This is new to me. Tell me more about optional form focus.

Try google, and you'll notice the cursor ends up in the search field
when the page loads, so you can begin typing without having to do any
navigation. Even for sighted users this is a nice usability feature so
you don't have to grab the mouse and place the cursor there manually
before typing.  This strategy should only be used though when the
primary content of a page is expected to be a form. Some users though
may prefer to navigate to the form, so they can potentially access other
features on the page prior to the form.  If the system provides for user
preferences, one of those preferences might be "turn on/off form focus".
We do this in ATutor, as an example.  If off, the cursor starts at the
top left of the page as usual. If on the cursor is sent to the first
field in the form when the page loads. Be careful with the latter, if
tabindexes are being used on the page. They may defeat the purpose of
auto form focus.


>> Careful with accesskeys, this is an ongoing issue, to which some
>> accessibility advocates think they should be eliminated alltogether.
>> Really, only numbers are safe to use as accesskeys to ensure they won't
>> conflict with AT or browser keys. The problem is really in the design or
>> implementation of the HTML accesskey element, which should allow user
>> agents (browsers or AT) to be distinguished from Web applications.  I'm
>> currently doing a review of Plone. They have created accesskeys that use
>> both the ctrl and alt keys, in addition to the assigned key, which seems
>> to get around the problem of conflicting keys
>>   
>
> Accesskeys are indeed an open issue, and I'm torn about their
> usefulness. There is a set of numerical keys that's been proposed by
> the UK Gov't e-Commerce group, but they target general content areas
> (like Help and News) and don't address controls. It's too bad there
> isn't more consistently in how browsers treat them; you can avoid the
> conflict in IE by pressing alt + letter concurrently for the web page.
> Alt + shift + the letter works for Firefox. Pressing alt + letter
> separately for the browser works for both. But I don't know how many
> screen reader users know that. You can also go to buttons on a page by
> pressing "b" with JAWS, but likewise don't know how many screen
> readers know that. <sigh> Suggestions on how to proceed with this?

Personally I'm against any standardization of numbered accesskeys. What
they've suggested would not work in most systems In ATutor  for
instance, it uses number accesskeys for the main navigation tabs in the
sequence they appear on the page. E.g the first tab alt-1, the second
tab alt-2 etc. We also use a standard "s" for submit on form pages, a
standard "c" for jump to content top, and a standard "m" for jump to
menu.  Yes, the letter keys do conflict in a few cases, but they add
more to the usability of the application than they take away from user
agents that might use them.  Systems vary so much, a standard set of 10
accesskeys would not be adaptable enough to be useful for most systems.
We're going to look into the Plone ctrl+alt strategy to see what we
might be able to do with that for creating letter-based  (thus more
memorable) accesskeys for navigating within pages of Web applications.
Ideally though the HTML spec should be changed so accesskeys for Web
content, differ from accesskeys for desktop applications. Changing the
spec for accesskeys to Alt+shift, or perhaps Alt+crtl, seems like a
logical direction for HTML.

greg