Accessibility Considerations for Design Patterns

[Michael S Elledge]

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.
>>     
>
>
> 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.
>   
Three sounds like a good number to me!
>   
>>>  
>>>
>>>       
>>>>> 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. 
>   
No, no! Just pointing out that any standardization will cause problems. 
I was really thinking of the UK numerical key scheme, though, since it 
seems to be the one instance of standardization I've come across.
> 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.
>   
That would be sweet. Does the ATRC have some influence there?
>   
>>> 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.
>   
Sorry for the confusion. I was thinking of whether the alt + shift  
functionality could be retrofitted through an update, although the 
people who don't upgrade their browsers might not implement a patch 
anyway, now that I think of it.
> 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/b78e5096/attachment.vcf>