Thread Subject: Re: platforms
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: Gregg Vanderheiden
Date: Tue, Apr 03 2007 8:30 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Gregg Vanderheiden: "Re: platforms"
- Previous message in thread: Gregg Vanderheiden: "Re: platforms"
- Messages sorted by: Author | Thread | Date
Good post Allen. Thanks.
One thing we also need to keep in mind is that APIs may work for some types
of AT (Installable) but won't work for others (attachable) or for personal
AT (like hearing aids, prosthetic hands, etc).
If we say that information needs to be available for AT - what does it mean?
Are we OK because it is clear which type of AT we mean?
Are the other AT covered elsewhere?
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: Tuesday, April 03, 2007 8:56 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] platforms
> I promised some info on platforms but while I have collected
> quite a lot, it isn't anything that really seems
> revolutionary. What I'd like to do is insert some references
> here, a bit of discussion, and finally suggest that we
> approach accessibility as it relates to platforms from a
> service-oriented architecture perspective. Maybe if we do
> that, apply service-oriented architecture methodology and
> concepts in an accessibility framework we can get reliable
> terms and concepts to use to represent our ideas.
> Maybe this "bit" of info can get us started to think this
> platforms topic through...
> To be honest I think this has great connection to the API proposal, as
> API(s) are the most obviously reusable/reliable "connectors"
> for accessibility services and service-users to lower the
> barriers to creation of and distribution of assistive technologies.
> Electronic and information technology is composed of
> combinations of interoperating components which as a whole
> provide information and data to end-users. A desktop
> computer's hardware provides physical information storage and
> processing as well as user-interaction mechanisms, the
> firmware or basic input/output system, BIOS provides a layer
> of interactivity to an operating system to use the hardware,
> the operating system provides a set of services to
> applications which run on it, and provides interface
> mechanisms to end-users, applications provide interpretation
> of encoded formats and interact with end-users via built-in
> or utilized interface services, and some applications provide
> interfaces to others in a multi-layered fashion. The
> "accessibility stack" includes all the layers of such
> components, with accessibility requirements for each layer
> potentially varying, but gaps in any able to break the whole.
> To more concisely define requirements which rely on the
> context of the location within an accessibility stack, some
> concepts may be helpful. First, there are service providers,
> and there are service users. Service providers "do
> something" for another requestor or caller, while service
> users request something be done. For example, an application
> may request the operating system to display a character, or
> in reverse the operating system may request that an
> application release focus to allow for an alternate task or
> process to take priority. it must be said that there are no
> clear cut boundaries between operating systems and
> applications, service providers and service users in the real
> world, so determining accessibility requirements only on that
> basis will be problematic in any actual implementation.
> To overcome this problematic implementation challenge, it may
> be possible to write standards in relationship to their
> service-providing or service using characteristics, or behavior.
> For example:
> When software provides content to be displayed to an
> end-user, the encoding scheme shall include sufficient
> accessibility attributes for the recipient application to use
> to ensure Section 508 compliance.
> Note, the statement could be rewritten to say the software
> will pass through all accessibility attributes of the encoding scheme.
> However, if we write:
> Operating systems shall provide a documented accessibility
> applications programming interface, or a consistent method to
> transfer accessibility attributes of interface and content
> elements, to and from an application.
> May be to proscriptive, since the service provider of that
> information may not be the OS, and could be, in fact, several
> discrete components acting together.
> Another way to write this statement regarding accessibility
> information may be:
> consistent information exchange methods which include a
> minimum set of accessibility attributes, per minimum API
> definition, and data shall be provided by software
> components to transfer information among interoperating
> components. Such consistent methods shall be documented by
> the developer or manufacturer of the software item.
> Some useful definitions from wikipedia:
> An operating system (OS) is a set of
> computer programs
> that manage the
> of a
> . An operating system rationally processes electronic devices
> in response to approved commands. At the foundation of all
> system software, an operating system performs basic tasks
> such as controlling and allocating memory , prioritizing
> system requests, controlling input and output devices,
> facilitating networking , and managing file systems . Most
> operating systems have a command line interpreter as a basic
> user interface, but they may also provide a graphical user interface
> (GUI) for ease of operation. The operating system forms a
> platform for other system software and for application software.
> See Wikipedia entry on "platform".
> See wikipedia on service-oriented architecture
> See this article on service-oriented architecture: