Thread Subject: Re: Proposal remote access requirements

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: Peter Wallack
Date: Thu, Jun 21 2007 11:25 AM

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Allen --<br>
I really wasn't asking the question with the intent of specifically
excluding 'web conferencing'; I was truly just trying to clarify my
interpretation of it!&nbsp; In fact, it is probably wiser not to
specifically exclude it. I may be way off base here, but my
understanding of this class of software is that it typically just sends
pixels across the wire, not interface element definitions, so of course
the receiving end cannot decipher it beyond just re-rendering those
pixels. But if someone is clever enough to solve that, we certainly
should not be discouraging them from doing so.<br>
<pre class="moz-signature" cols="72">Peter Wallack
Accessibility Program Director
Oracle Corporation</pre>
<br>
<br>
Hoffman, Allen wrote:
<blockquote
cite="mid: = EMAIL ADDRESS REMOVED = "
type="cite">
<pre wrap="">Peter:

When i wrote this I didn't intend to include and exclude specific items
exactly, but to try and describe what we needed for certain remote
access situations for when one system is the remote terminal for
operations on another. I restricted it to operation of a graphical user
interface on purpose because I'm aiming for products such as
remote-desktop, Citrix, etc that allow real OS level access to another
system and its applications. I think web conferencing would not fit
this definition as it is covered by web and other software provisions
already, and it is a less holistic remote access than what I'm driving
for. To improve the proposed language I could include:

Original: When software provides either server or client functionality
for
remote access to a specific graphical user interface, such software
MUST make available interface element accessibility information from
the server to the client to be inspected by assistive technologies.

Changed to: When software provides either server or client functionality
for
remote access to a specific graphical user interface, except for
web-conferencing, such software MUST make available interface element
accessibility information from
the server to the client to be inspected by assistive technologies.

I'd be interested to hear from AT vendors on how they have made such
remote access mechanisms work to date, and where they feel gaps are.



Allen Hoffman -- <a class="moz-txt-link-abbreviated" href="mailto: = EMAIL ADDRESS REMOVED = "> = EMAIL ADDRESS REMOVED = </a>; v: 202-447-0303

-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto: = EMAIL ADDRESS REMOVED = "> = EMAIL ADDRESS REMOVED = </a>
[<a class="moz-txt-link-freetext" href="mailto: = EMAIL ADDRESS REMOVED = ">mailto: = EMAIL ADDRESS REMOVED = </a>] On Behalf Of Peter
Wallack
Sent: Wednesday, June 20, 2007 7:21 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Proposal remote access requirements

Can someone please clarify whether this definition is intended to
include or exclude web conferencing (like WebEx)

Peter Wallack
Accessibility Program Director
Oracle Corporation



Tom Brett wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I propose that we say:

When software provides either server or client functionality for
remote access to a specific graphical user interface, such software
MUST make available interface element accessibility information from
the server to the client to be inspected by assistive technologies.


Tom Brett


-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto: = EMAIL ADDRESS REMOVED = "> = EMAIL ADDRESS REMOVED = </a>
[<a class="moz-txt-link-freetext" href="mailto: = EMAIL ADDRESS REMOVED = ">mailto: = EMAIL ADDRESS REMOVED = </a>] On Behalf Of
Hoffman, Allen
Sent: Wednesday, June 20, 2007 1:40 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Proposal remote access requirements

The following are ideas and discussion items regarding accessibility
requirements for remote access applications.

Background:

Currently often remote access from one system to another is
implemented using text-based terminal emulation such as VT100, or 3270
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">protocols and clients, graphical user interfaces such as X-windows,
and remote-desktop-protocol, and variations of each. For text-based
remote access, scrolling text windows can be problematic for some
assistive technologies to handle as much of that type of access was
dropped when such technologies migrated from text-based OS(s) to
graphical user interfaces. In graphical user interfaces such as
X-windows, remote-desktop-protocol, etc, often assistive technologies
must be operated on the server end, with sound being transmitted to
</pre>
</blockquote>
<pre wrap=""><!---->the client.
</pre>
<blockquote type="cite">
<pre wrap="">What is needed is that the client receives enough of the underlying
accessibility information for each interface element from the remote
end to pass to the assistive technology on the client end.

Proposed standard:

When software provides either server or client functionality for
remote access to a specific graphical user interface, such software
MUST pass interface element accessibility information from (proposed
21D) from the server to the client to then be passed to or inspected
by assistive technologies.

Note:
I think we can exempt web browsers from this requirement as there are
already other specific requirements for how content shall work in that
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">context.

I hope this is a start for discussion that we can wrap up fairly
quickly.
Sean, if you can comment on how RDP functions that would be
enlightening.
Peter, when you are back from vacation, a comment on how Gnome works
during remote access would help.

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University