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: Jim Tobias
Date: Tue, Mar 27 2007 11:40 AM

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