Thread Subject: Re: SUSPECT: Re: 3-u explanatory information
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: Hoffman, Allen
Date: Tue, Mar 18 2008 1:00 PM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: None
- Previous message in thread: None
- Messages sorted by: Author | Thread | Date
Mary:
The point is that for platforms which don't support interoperability of
this kind, they won't provide this information anyway, so the point is
mute. If the platform provides accessibility stand-alone, it an do it
in anyway it deems is best.
Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
= EMAIL ADDRESS REMOVED =
Sent: Tuesday, March 18, 2008 2:34 PM
To: TEITAC Committee
Subject: SUSPECT: Re: [teitac-committee] 3-u explanatory information
Mary:
On the question of scope, the entire provision begins "On platforms that
support AT-E&IT interoperability"
W
> -------- Original Message --------
> Subject: [teitac-committee] 3-u explanatory information
> From: "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = >
> Date: Tue, March 18, 2008 11:25 am
> To: "TEITAC Committee" < = EMAIL ADDRESS REMOVED = >
>
> This is for Mary Brunner, hope it helps.
>
> This provision is intended to define clearly a minimum set of
> information that must be made available in some organized way to allow
> other software, including assistive technology software, to provide
> the information of the user-interface to people with disabilities in
> other ways than the normally visual presentation.
>
> So, for example:
>
>
> 1. provide assistive technology with object information including but
> not limited to:
>
> a. role, state(s), boundary, name, and description
>
> The role is what kind of control or interface-component this
> is--slider bar, button, etc.
> State is something like pressed, on/off, etc.
> boundary is the visual perimeter of the element. If someone uses
> screen magnification they may need to know the size of the item they
> are looking at, as opposed to other visual information.
> name is the label of the control, e.g. OK-button.
> Description can be additional information about this control that is
> helpful.
>
> I can describe all of these below, but does this help?
>
> The paragraph at the top basically says that software should use
> available organized services to deliver these kinds of information
> when they are available, as opposed to just make up their own for each
> application. AT vendors can't keep up with application by application
> methods, and when available can use platform provided information far
> more reliably.
>
>
>
> b
> 3-U - AT Interoperability
>
> (Moved for discussion purposes to
> Collection on AT-IT )
>
> On platforms that support AT interoperability, software that provides
> user interface components must either use the accessibility services
> provided by platform software or other services to cooperate with
> assistive technologies when such services allow the software to meet
> the accessibility provisions of this standard. Using such services,
> software must:
>
> 1. provide assistive technology with object information including but
> not limited to:
>
> a. role, state(s), boundary, name, and description
>
> b. the row and column a component is in, and the headers for the row
> and column for
> that component if it is in a table that has row or column headers,
>
> c. current value and any minimum or maximum values, if the component
> represents one
> of a range of values
>
> d. relationship this component has as a label for another component,
> or being labeled
> by another component
>
> e. parent or containing element, and any children components
>
> f. text contents, text attributes, and the boundary of text rendered
> to the screen.
>
> Note: In order to meet this provision, interactive elements encoded in
> data operated on by the software would need to be associated with
> sufficient information to determine a role, state(s), name, and
> description for the interactive element, that the software can obtain
> as readily as it can obtain the interactive element itself.
>
> 2. provide assistive technology with a list of actions that can be
> executed on an object and allow assistive technology to
> programmatically execute any of those actions;
>
> 3. allow assistive technology to track and modify focus, text
> insertion point, and selection attributes of user interface
> components;
>
>
> 4. provide assistive technology with notification of events relevant
> to user interactions, including but not limited to changes in the
> component's state(s), value, name, description, or boundary
>
> Note 1:This provision applies to forms in the software.
>
> Note 2: Software that provides remote access to graphical user
> interfaces (GUIs) would need to ensure that AT has access to the
> information required by this provision.
> There are two known ways to accomplish this: run the AT remotely as
> well or run the AT locally and provide a mechanism for it to
> communicate accessibility information with the remote GUI.
>
> Note 3 (proposed by Trace 2/26): The term 'assistive technology' in
> this provision and provision 3-V-Accessibility Services refers to
> assistive technology that exists and that is available to government
> employees (or members of the public for public facing E&IT).
>
> Rationale: The current provisions in Section 508 that address
> interoperability with AT are 1194.21(c), 1194.21(d) and 1194.21(f).
> "Sufficient information" in
> 1194.21(d) is not testable and the three requirements together are
> insufficient to meet the needs of assistive technology. The proposed
> provision is much more comprehensive. It details what type of object
> information must be provided and includes event notification which is
> critical for assistive technology interoperability.
> It is also harmonized with ISO 9241-171 and is supported by the major
> accessibility APIs on desktop operating systems. The phrase beginning
> "or other services to cooperate with assistive technologies" is
> provided to allow for other methods of cooperating with assistive
> technology where platforms and APIs are insufficiently mature to
> support the necessary functions.
>
> Note: The word "components" was used in this provision instead of
> "objects" since objects is a programming term and can be confusing to
> vendors. By using the term components it is more generic and will
> hopefully lead to less confusion.
> list of 7 items
> * Status: Not discussed yet
> * Text from Web and Software
> * Source: {508}1194.21(d), (c), & (f)
> * Impact: Significant
> list of 1 items nesting level 1
> * More specificity of the information that must be exposed to AT.
> Significant positive impact to end users and agencies. IT-AT
> interoperability will be improved and less customization should be
> required.
> list end nesting level 1
> * External Reference: Harmonized with ISO 9241-171
> * Testability: Expert evaluation
> * Disabilities: Blindness
> list end
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
>
>
>
- Next message in Thread: None
- Previous message in Thread: None