Thread Subject: Re: FW: Starting discussions on theAccessibility APIproposal
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: Travis Roth
Date: Wed, Dec 20 2006 12:45 PM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Gregg Vanderheiden: "Re: Starting discussions on the AccessibilityAPIproposal"
- Previous message in thread: Peter Korn: "Re: FW: Starting discussions on the Accessibility APIproposal"
- Messages sorted by: Author | Thread | Date
> 2. Under additional object information needed for editable text
> objects, there is an information about "the bounding rectangle of each
> character of text". Having a bounding rectangle of each character of
> text is not necesarry. The most important thing is to have the text
> insertion carat and have the bounding rectangle on the input field of
> the editable text so that it is clear as well for the screen magnifier
> which is the focus it needs to present to the users. That means AT
> will not only sets the focus to the character but also to the object
> surrounded the editable text.
>
> We've thought about (and argued internally within Sun) about this issue
> a lot. The reasons we decided to include character bounding rectangles
> were to support several AT use cases that we didn't see a clean route to
> providing otherwise. On the other hand, this is one of the more
> difficult things for some software applications to provide.
> The use cases include:
> a. TextHelp / ZoomText AppReader / WYNN functionality where portions of
> the text are highlighted as they are read with speech - including the
> sentence, line, word, and character
> b. Proportional Braille line formatting, as used in European screen
> readers, where in "full screen review" mode text is spaced appropriately
> to show vertical alignment [thus a row of the 'i' characters above a
> row of the 'w' characters in a proportional spaced found would be
> rendered in Braille with blank Braille cells within the row of 'i'
> characters.
I would also submit a possible use case of:
c. This information can enable AT to select or convey selection, when a key
on a braille display is pressed to move focus to a specific character. This
is often referred to as cursor routing. There may be other programmatical
means to do this as well.
--
Travis Roth
Production Manager
TecAccess, LLC
(804) 749-8646 (office)
(402) 466-0907 (direct)
= EMAIL ADDRESS REMOVED =
www.TecAccess.net
Experts in Section 508 Compliance & Accessibility
NOTICE: This communication may contain privileged or other confidential
information. If you are not the intended recipient or believe that you may
have
received this communication in error, please reply to the sender indicating
that fact and delete the copy you received. Thank you.
- Next message in Thread: Gregg Vanderheiden: "Re: Starting discussions on the AccessibilityAPIproposal"
- Previous message in Thread: Peter Korn: "Re: FW: Starting discussions on the Accessibility APIproposal"