Accessibility Considerations for Design Patterns

[Michael S Elledge]

Hi Greg! Thanks!

Greg Gay wrote:
> 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.
>   
>>> 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...
> 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...
> 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.

Mike
> greg
>
>
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elledge.vcf
Type: text/x-vcard
Size: 313 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070815/a1e1eb56/attachment.vcf>