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.
>>
>>   
>
> That's interesting. I hadn't thought of having this as an option.
> Another way to do this, which would be page-specific (better, perhaps)
> would be to provide a link at the top of the page that says "Go
> directly to form" with an anchor tag.


It maybe better. It deals with the complaint by those who don't like the
auto form focus. Which is the main reason for including it as an option.
One other consideration for some apps is the number of bypass links.
I've seen four or five in some cases, which might warrant a bypass link
to skip over the bypass links  ;-)

We try to keep bypass links to a maximum of three.

>>  
>>
>>>> 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.  
>
> That's true, but as much as I admire ATutor it is only one application...

I'm not suggesting standardizing those keys, if that's what you mean. 
We use them, because they work well mnemonically, and they don't
conflict too seriously with other applications. My mentioning the
accesskey strategy in ATutor was just to demostrate that stardardize
keys would not work for us.

>> 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.
>>   
>
> I'm not familiar with Plone. Given Firefox's popularity and the work
> that's been done to make it screen reader compatible (by IBM) you may
> want to consider the alt + shift route, too...

Plone is a fairly popular Zope based content management system,
something like Drupal, or Joomla.

IE is still the browser of choice for the vast majority of AT users. 
JAWS still has trouble with Firefox. So at this point we don't have much
choice but to make things usable with IE. Now if IE would only implement
accesskeys like Firefox has, that might be all we need to deal with the
conflicting accesskey issue.

>> 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.
>>   
>
> A possible issue could be the added keystrokes needed for some persons
> with dexterity problems. But that would probably be minor compared to
> having consistent treatment of accesskeys by browsers. Could something
> like that be retrofitted to existing browsers? In our experience,
> screen reader users don't update their systems regularly.

Yes, extra keystrokes will be more effortful for some, though most with
serious motor impairments will use sticky keys to get around that.

For me the consistent implementation of accesskeys across browsers is
less important than dealing with the conflicts. People will usually
figure out the differences, and most will use one browser for most of
their web browsing, so the differences between browsers don't really
come into play for most people.

greg