Thread Subject: Re: 21 g - revision
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:05 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Peter Korn: "Re: 21 g - revision"
- Previous message in thread: Andi Snow-Weaver: "Re: 21 g - revision"
- Messages sorted by: Author | Thread | Date
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?
> -----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.
> 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
> >> 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