Thread Subject: Re: 21 g - revision

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Peter Korn
Date: Tue, Mar 27 2007 12:50 PM

Hi Jim,

I think the mis-communication between us here has to do with
presumptions about who owns what code doing which tasks.

When I read what you wrote (below), I'm making the assumption that you
suggest an application should notice a system setting for "mouse trails"
(and perhaps another for "enlarged mouse cursor"), and then when the
application has a custom cursor, it must then re-implement mouse trail
functionality and mouse enlargement functionality in its own app. This
implies to me that every application that has a custom mouse cursor must
re-implement the same trail & enlargement code.

Contrast that with one implementation of mouse trails (and enlargement)
that simply gets information about the mouse cursor pixels in a standard
way from every application that has a custom mouse cursor.

It is important that we take care in our 508 language to not dictate
precisely how something must be accomplished, so long as it is
accomplished. Nonetheless, I think all would agree that less code
duplication is better than more. I think most would agree that the less
work it is to make an application accessible & compatible with AT, the
better. Therefore, I suggest that it makes more sense to encourage apps
to communicate what they are doing to adaptation code like mouse trails
& mouse enlargement, vs. re-implementing trails & enlargement themselves.


Regards,

Peter


> Maybe I'm missing the complexity here, but I don't see the problem. The
> OS should expose the default cursor and its relevant characteristics. That
> is,
> not just pass a file pointer to the cursor's image, but also its size, video
> characteristics, trails on/off setting, etc. And then the app should
> respond
> to those settings appropriately, either by inheriting the cursor or by
> applying the
> characteristics to the app's custom cursor(s).
>
> I don't see that these "penalize" either party.
>
> ***
> Jim Tobias
> Inclusive Technologies
> +1.732.441.0831 v/tty
> +1.908.907.2387 mobile
> skype jimtobias
>
>
>
>> -----Original Message-----
>> From: Peter Korn [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Tuesday, March 27, 2007 2:19 PM
>> To: TEITAC Web/Software Subcommittee
>> Subject: Re: [teitac-websoftware] 21 g - revision
>>
>> Hi Jim,
>>
>> If the user indicates a preference for "mouse trails", then
>> that should continue to work (and the implementation of
>> "mouse trails" should provide a way for application vendors
>> to use their own mouse cursors that is compatible with "mouse
>> trails"). Similarly any feature that enlarges just the mouse
>> (whether from a 3rd party AT vendor, or from the OS/platform
>> vendor) - there must be a way for applications to work with
>> such a feature, even with their own custom mouse cursors.
>>
>> It absolutely shouldn't be all or nothing.
>>
>> But... if the folks making the "mouse enhancement" features
>> (whether they are AT vendors or the OS/platform vendors) fail
>> to provide a way for their enhancement to work with custom
>> mouse cursors, then who should be "penalized"? Do we (in
>> effect) penalize the application vendor (and by extension all
>> mainstream software users) by disallowing custom mouse
>> cursors? Do we (in effect) penalize users with vision
>> impairments who need this feature by failing to require that
>> they be supported? Do we (in effect) penalize AT by bringing
>> AT under 508 and requiring that (at least magnification
>> products) be compatible with IT in this area? Do we (in
>> effect) penalize the OS/platform by bringing this under 508
>> and requiring that they provide "accessibility services"
>> (what I call an accessibility API) that covers this scenario?
>>
>> We have to make one of these four choices. Failing to
>> specify anything in effect makes the second choice - users
>> vision impairments may fail to have mouse cursor enhancements
>> work with custom mouse cursors in some of the applications
>> they want to use.
>>
>>
>> Regards,
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>>
>>
>>> I see what you're saying about modifying the cursor, but is
>>>
>> it really
>>
>>> an all-or-nothing situation? I'm not speaking against an API
>>> solution, but why not put something specific here that approximates
>>> the user's clearly indicated preferences?
>>>
>>> ***
>>> Jim Tobias
>>> Inclusive Technologies
>>> +1.732.441.0831 v/tty
>>> +1.908.907.2387 mobile
>>> skype jimtobias
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Peter Korn [mailto: = EMAIL ADDRESS REMOVED = ]
>>>> Sent: Tuesday, March 27, 2007 1:48 PM
>>>> To: TEITAC Web/Software Subcommittee
>>>> Subject: Re: [teitac-websoftware] 21 g - revision
>>>>
>>>> Hi Jim,
>>>>
>>>> Your example (below) illustrates to me one of the problems
>>>>
>> with parts
>>
>>>> of our current technical specifications in 1194.21, and also why I
>>>> continue to push for API-based solutions.
>>>>
>>>> Telling developers they must only use one of a handful of
>>>> system-specified mouse cursors restricts their innovation.
>>>> telling developers they must expose the pixels of their
>>>>
>> mouse cursor
>>
>>>> and signal when the mouse cursor changes allows AT (and in
>>>>
>> this case
>>
>>>> magnifiers) to do the right things for their users. For example,
>>>> think about all of the mouse cursor shapes that a product
>>>>
>> like Adobe
>>
>>>> Photoshop or Adobe Illustrator use - to cleanly indicate
>>>>
>> the nature
>>
>>>> of the mouse operations available. Better to allow Adobe
>>>>
>> to do this,
>>
>>>> and provide a way for AT to easily magnify
>>>>
>> non-system-provided mouse
>>
>>>> cursors.
>>>>
>>>> It should come as no surprise that our UNIX accessibility
>>>>
>> framework
>>
>>>> provides this information, and magnification on our platform
>>>> correctly handles mouse cursor shape changes.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Peter Korn
>>>> Accessibility Architect,
>>>> Sun Microsystems, Inc.
>>>>
>>>>
>>>>
>>>>> One other display attribute that might be usefully added to
>>>>>
>>>>>
>>>> a revised
>>>>
>>>>
>>>>> 21(g) is the cursor: its size, shape, coloring (e.g.
>>>>>
>> black, white,
>>
>>>>> inverse, etc.), and presence/absence of "trails". I know
>>>>>
>> of several
>>
>>>>> applications that replace the system cursor with an
>>>>>
>>>>>
>>>> app-specific one
>>>>
>>>>
>>>>> to the detriment of low vision users.
>>>>>
>>>>> ***
>>>>> Jim Tobias
>>>>> Inclusive Technologies
>>>>> +1.732.441.0831 v/tty
>>>>> +1.908.907.2387 mobile
>>>>> skype jimtobias
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Andi Snow-Weaver [mailto: = EMAIL ADDRESS REMOVED = ]
>>>>>> Sent: Tuesday, March 27, 2007 1:22 PM
>>>>>> To: TEITAC Web/Software Subcommittee
>>>>>> Subject: Re: [teitac-websoftware] 21 g - revision
>>>>>>
>>>>>> The wording in the 21(g) proposal that seems to be causing the
>>>>>> concern was chosen to improve the existing 21(g) and
>>>>>>
>> harmonize it
>>
>>>>>> with 21(b) which also uses that wording.
>>>>>>
>>>>>> Current wording:
>>>>>>
>>>>>> 21(b) Applications shall not disrupt or disable activated
>>>>>>
>>>>>>
>>>> features of
>>>>
>>>>
>>>>>> other products that are identified as accessibility
>>>>>>
>>>>>>
>>>> features, where
>>>>
>>>>
>>>>>> those features are developed and documented according to
>>>>>>
>> industry
>>
>>>>>> standards.
>>>>>> Applications also shall not disrupt or disable activated
>>>>>>
>>>>>>
>>>> features of
>>>>
>>>>
>>>>>> any operating system that are identified as
>>>>>>
>> accessibility features
>>
>>>>>> where the application programming interface for those
>>>>>>
>>>>>>
>>>> accessibility
>>>>
>>>>
>>>>>> features has been documented by the manufacturer of the
>>>>>>
>> operating
>>
>>>>>> system and is available to the product developer.
>>>>>>
>>>>>> 21(g) Applications shall not override user selected contrast and
>>>>>> color selections and other individual display attributes.
>>>>>>
>>>>>> Proposed wording:
>>>>>>
>>>>>> 21(b) - no change. We discussed the testabilty issues with
>>>>>> 21(b) but were unable to reach consensus on a recommendation for
>>>>>> changing the wording.
>>>>>>
>>>>>> 21(g) Applications shall utilize user selected contrast
>>>>>>
>> and color
>>
>>>>>> selections and other individual display attributes when the
>>>>>> availability of those selections are developed and documented
>>>>>> according to industry standards.
>>>>>>
>>>>>> The problem with the original wording is that "other individual
>>>>>> display attributes" is very vague. The proposed wording
>>>>>>
>>>>>>
>>>> was viewed as
>>>>
>>>>
>>>>>> an improvement, although certainly not perfect.
>>>>>>
>>>>>> Andi
>>>>>>
>>>>>>
>>>>>>
>>>>>>

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University