Thread Subject: 1194.22(b) in Group A: Re: Jim Tobias' commentabout requiring AT

Return to this mailing list's archives

From: Peter Korn
Date: Thu, Oct 19 2006 11:55 AM
Subject: 1194.22(b) in Group A: Re: Jim Tobias' commentabout requiring AT

Jim's comment on 1194.22(b) is:

'Jim Tobias: Going beyond this provision, how about requiring
operating systems to include certain accessibility features? The major
operating systems do have such features. The list of required features
would
have to be decided upon, and even more difficult, an agreement as to what
constitutes an "operating system".'

I am a bit concerned with this. While I'm delighted to see what appears
to be actual competition among OS vendors in bundling AT with their OSes
(as we now have competition in car manufacturers as to how may air bags
they have), I do not think we should require that. I think it is wrong
to place a barrier to entry in the OS market saying that you have to
provide specific AT with your OS, or specific "accessibility features".

I believe we should have outcomes-based requirements (e.g. "a user must
be able to operate all keyboard functions with a single keypress"), and
then recommend specific guidance as to how to accomplish thing (e.g.
"cf. StickyKeys capabilities for latching keyboard modifiers"), and the
finally ensure that we don't foreclose innovation (by maintaining 1194.5
Equivalent facilitation "Nothing in this part is intended to prevent the
use of designs or technologies as alternatives to those prescribed in
this part provided they result in substantially equivalent or greater
access to and use of a product for people with disabilities.").

I would not explicitly require in 508 that all OSes must include
StickyKeys, even though the three most popular desktops (Windows, Mac,
UNIX) already do.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

From: Andi Snow-Weaver
Date: Thu, Oct 19 2006 12:50 PM
Subject: Re: 1194.22(b) in Group A: Re: Jim Tobias'comment about requiring AT

<beginning of Peter's comment>

"I believe we should have outcomes-based requirements (e.g. "a user must
be able to operate all keyboard functions with a single keypress"), and
then recommend specific guidance as to how to accomplish thing (e.g.
"cf. StickyKeys capabilities for latching keyboard modifiers"), and the
finally ensure that we don't foreclose innovation (by maintaining 1194.5
Equivalent facilitation "Nothing in this part is intended to prevent the
use of designs or technologies as alternatives to those prescribed in
this part provided they result in substantially equivalent or greater
access to and use of a product for people with disabilities.")."

<end of Peter's comment>

Peter, I understand the desire for not making 508 too prescriptive about
where the function must be provided but this approach complicates
compliance reporting for multi-platform products. If your software depends
on StickyKeys in the OS to support this requirement, then the same software
product will be 508 compliant on platforms that include StickyKeys but
non-compliant on platforms that don't.

Andi

From: Jim Tobias
Date: Thu, Oct 19 2006 7:05 PM
Subject: Re: 1194.22(b) in Group A: Re: Jim Tobias'commentabout requiring AT

> -----Original Message-----
> From: Peter Korn [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, October 19, 2006 1:53 PM
> To: TEITAC Web/Software Subcommittee
> Subject: [teitac-websoftware] 1194.22(b) in Group A: Re: Jim
> Tobias' commentabout requiring AT
>
> Jim's comment on 1194.22(b) is:
>
> 'Jim Tobias: Going beyond this provision, how about requiring
> operating systems to include certain accessibility features?
> The major operating systems do have such features. The list
> of required features would have to be decided upon, and even
> more difficult, an agreement as to what constitutes an
> "operating system".'
>
> I am a bit concerned with this. While I'm delighted to see
> what appears to be actual competition among OS vendors in
> bundling AT with their OSes (as we now have competition in
> car manufacturers as to how may air bags they have), I do not
> think we should require that. I think it is wrong to place a
> barrier to entry in the OS market saying that you have to
> provide specific AT with your OS, or specific "accessibility
> features".

What is so special about OSs versus application software or websites? How
could it be "wrong" to require OSs, but not apps and sites, to have certain
accessibility features? You may have thought I meant screen readers; I
didn't. I intended us to consider creating a floor for OSs, so that all
future versions would have to have the same kinds of features they have now,
like StickyKeys, etc. Otherwise we risk an unlevel playing field indeed.
Suppose that someone comes up with a really stripped-down OS that can run
the apps an agency needs, but the OS has no accessibility features. Under
the current regs, the app complies with the "do not disrupt" provision, but
since there's nothing in the OS, the user cannot access the app. My
proposal would eliminate the current lack of accessibility requirements for
OSs.

> I believe we should have outcomes-based requirements (e.g. "a
> user must be able to operate all keyboard functions with a
> single keypress"), and then recommend specific guidance as to
> how to accomplish thing (e.g.
> "cf. StickyKeys capabilities for latching keyboard
> modifiers"), and the finally ensure that we don't foreclose
> innovation (by maintaining 1194.5 Equivalent facilitation
> "Nothing in this part is intended to prevent the use of
> designs or technologies as alternatives to those prescribed
> in this part provided they result in substantially equivalent
> or greater access to and use of a product for people with
> disabilities.").
>
> I would not explicitly require in 508 that all OSes must
> include StickyKeys, even though the three most popular
> desktops (Windows, Mac, UNIX) already do.

I'm not sure I really understand your position. Let me try to rephrase what
you've written. Assuming the equivalent facilitation language, would you
support language that says "the operating system must allow a user to
operate all keyboard functions with a single keypress"? If not, why not?

From: Tamas Babinszki
Date: Thu, Oct 19 2006 7:50 PM
Subject: Re: 1194.22(b) in Group A: Re: Jim Tobias'commentabout requiring AT

Peter writes:
"I am a bit concerned with this. While I'm delighted to see what appears to
be actual competition among OS vendors in bundling AT with their operating
systems (as we now have competition in car manufacturers as to how may air
bags they have), I do not think we should require that. I think it is wrong
to place a barrier to entry in the OS market saying that you have to provide
specific AT with your OS, or specific "accessibility features"."

I think operating systems should contain certain accessibility features.
When accessibility features are missing, the operating system maybe such
that a software running under it might not be able to be accessible.
Consider the Orca project for Linux for example. Without implementing a
level of accessibility features into the OS, assistive technologies would
have nothing to rely on. Also, it would be a huge Burdon on the software
manufacturers to come up with their own accessibility features, which would
also restrict usability, given that the users would have to learn to use
them every time they learn a new software.

An other thought I have about operating systems, is that all operating
systems can be classified as software, but not all softwares are operating
systems. Thus, operating systems should be compliant with all standards,
after all, they are also constitute as a government purchase. I would like
to see some standards, which set the foundation of a solid and accessible
operating systems, so that all applications and assistive technologies would
be able to run on them.

Tamas

From: Jessica M. Brodey
Date: Thu, Oct 19 2006 9:50 PM
Subject: Re: 1194.22(b) in Group A: Re: JimTobias'commentabout requiring AT

Tamas writes:
"An other thought I have about operating systems, is that all operating
systems can be classified as software, but not all softwares are operating
systems. Thus, operating systems should be compliant with all standards,
after all, they are also constitute as a government purchase. I would like
to see some standards, which set the foundation of a solid and accessible
operating systems, so that all applications and assistive technologies would
be able to run on them."

Interoperability is certainly a key issue for ATIA. For us, we would not
necessarily argue to natively building in all accessibility features all the
time - at times it is appropriate for features to be add-on assistive
technology and sold separately. However, it is necessary that all systems
and software be designed so that AT can easily be added on to the system so
that it is fully integrated and interoperable. Today, it is not easy to
plug in an alternate computer access device (switch, sip and puff, eye
tracker) and be certain that it will consistently control every piece of
software in the same manner that a mouse works. As we move forward, it will
be critical for us to determine which accessibility features are critical
for access, and what features and components are at the core of ensuring
interoperability with AT.

From: Peter Korn
Date: Fri, Oct 20 2006 12:05 AM
Subject: Re: 1194.22(b) in Group A: Re: JimTobias' commentabout requiring AT

Hi Tamas,

I wrote initially:

""I am a bit concerned with this. While I'm delighted to see what
appears to
be actual competition among OS vendors in bundling AT with their operating
systems (as we now have competition in car manufacturers as to how may air
bags they have), I do not think we should require that. I think it is wrong
to place a barrier to entry in the OS market saying that you have to provide
specific AT with your OS, or specific "accessibility features".""

To which Tamas replied:

"I think operating systems should contain certain accessibility features.
When accessibility features are missing, the operating system maybe such
that a software running under it might not be able to be accessible.
Consider the Orca project for Linux for example. Without implementing a
level of accessibility features into the OS, assistive technologies would
have nothing to rely on. Also, it would be a huge Burdon on the software
manufacturers to come up with their own accessibility features, which would
also restrict usability, given that the users would have to learn to use
them every time they learn a new software."

I completely agree that this is the right way to do it. (no surprise,
as I was one of the folks who helped create the architecture in Linux
and UNIX that Orca is using). My concern is whether to explicitly
require it, or to recommend it as the best practice.

Perhaps this is not so important a distinction, as we have in 1194.5
Equivalent facilitation "Nothing in this part is intended to prevent the
use of designs or technologies as alternatives to those prescribed in
this part provided they result in substantially equivalent or greater
access to and use of a product for people with disabilities." So if we
prescribe that an OS must do something in 1194.21 or some other section,
1194.5 says that if what is acquired under 508 accomplishes the same
goals - e.g. the Functional performance criteria in 1194.31 - in some
other fashion, than all is fine.

My concern is simply that we not should hamper innovation toward
accomplishing equal or improved accessibility.

Tamas also wrote:

"An other thought I have about operating systems, is that all operating
systems can be classified as software, but not all softwares are operating
systems. Thus, operating systems should be compliant with all standards,
after all, they are also constitute as a government purchase. I would like
to see some standards, which set the foundation of a solid and accessible
operating systems, so that all applications and assistive technologies would
be able to run on them."

I agree, though I'd say it slightly differently. Virtually all
operating systems contain software applications, but few software
applications contain operating systems. Some of those are virtual
operating systems operating in another, host OS (e.g. VMware; and some
might see the Java platform or an X server as having some of these
characteristics).

I would say that all apps shipped with an OS (be it the calculator or
the printer setup dialog) should comply with all of the software
application accessibility guidelines [or provide equivalent
functionality some other way]. Likewise if we wind up making a separate
category for AT, then all AT that ships with an OS should comply with
those guidelines [or provide equivalent functionality some other way].

I think it would be very useful to describe a set of operating system,
or platform, features which we recommend they have to support
accessibility. I remain concerned with explicitly requiring them; at
least unless we enshrine equivalent facilitation for them such that if
the end-user goal is accomplished then the offering is said to meet 508.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

From: Peter Korn
Date: Fri, Oct 20 2006 12:50 AM
Subject: Re: 1194.22(b) in Group A: Re: JimTobias' commentabout requiring AT

Hi Jim,

[sorry for something of a top-post; I want to reply to multiple of your
comments all at once]

Perhaps I read more into your statement than was there. I did initially
presume a suggestion of more sophisticated "accessibility features" like
a screen reader. Also, the word "require" was a flag for me.

I believe we should strive to satisfy multiple,
not-necessarily-conflicting, goals:
1. Preserve maximum flexibility and opportunity for innovation in
addressing accessibility needs
2. Provide maximum clarity and measurability in the standards, to avoid
ambiguity and aid in the application of these standards by adopters and
implementors

So I think it makes sense to enumerate in some way the known best
practices and techniques in detail, while not requiring that those
techniques be the only way of realizing the outcome. As I noted in my
reply to Tamas, the language in 1194.5 may be sufficiently strong that
we can be prescriptive in 1194.21. I just want to be clear that any
other technique that achieves the accessibility outcome should be
acceptable.

You ask this specific question:
> Assuming the equivalent facilitation language, would you
> support language that says "the operating system must allow a user to
> operate all keyboard functions with a single keypress"? If not, why not?
>

I think your quoted language is essentially a specific example of the
general case stated in the existing 1194.31(f): "At least one mode of
operation and information retrieval that does not require fine motor
control or simultaneous actions and that is operable with limited reach
and strength shall be provided." Perhaps that specific example, among
others, should be enumerated somewhere, with a "cf. StickyKeys,
FilterKeys, BounceKeys" as a documented best practice. I'm not at all
against a statement generally along these lines.

But as you note elsewhere, this language brings up an issue I think we
need to discuss and illuminate more: what constitutes an "operating system".

1194.21 is "Software applications and operating systems", but most of it
is really about applications and about user interface frameworks (e.g.
the graphical toolkit like that in Win32 or in Java Swing) that are used
by applications to rendering graphical user interfaces. For example,
1194.21(c) isn't an OS function. Neither is 1194.21(a). Industry has
addressed 1194.21(d) through the development of accessibility
programming interfaces (or programming contracts) implemented by GUI
toolkits -> MSAA for Win32, the Apple Accessibility API on Carbon and
Cocoa, JAA for Java, and the GNOME Accessibility API in UNIX as
implemented by GTK+, UNO, XUL, and bridged from Java. Their adoption by
apps and AT is happening because they have become standard on their
respective operating systems/platforms. And a large number of
applications use 1194.21(d) to accomplish via equivalent facilitation
the specific technique prescribed in 1194.21(f) [things like Java
applications that use Java2D to decode and render Postscript fonts
directly; also things like X servers running on Windows that do their
own font rendering].


Clearly software applications and assistive technologies live on an
operating system, or at least on a "platform". And I feel that the
operating system/platform has a definite role to play in providing
accessibility. In any given OS, how the responsibilities are divided
amongst OS, app, and AT may differ (though again, we can have a best
practice that we reference/suggest).

For example, in the Java Standard Edition platform running on Windows or
Macintosh or UNIX, we don't need to provide something like StickyKeys
functionality because the "host OS" provides it; we simply need to not
break it. On the other hand, we do need to convey to Java applications
the desktop theme settings so that applications can recognize them,
respect them, and behave accordingly. In fact we do more than that -
for users of the Swing user interface toolkit who choose the default to
have their visual look match that of the desktop, we automatically
change that visual look so that it matches the desktop theme (which is
our interpretation of 1194.21(g)).


Let's look at another example: PDAs and cell phones are increasingly
running rich operating systems. Many are running Linux. Some have rich
GUIs (cf. the Nokia 770 Internet Tablet). Should 508 say that such a
device *must* have StickyKeys in order to be purchased under 508 (or at
least, must it have StickyKeys if it has a keyboard with modifier
keys)? What if instead the vendor offered a keyboard at the same price
as the standard keyboard that did the key latching itself? That feature
wouldn't be an "OS feature" at all; that is a hardware solution that
accomplishes the stated end user goal. What if all apps running on one
of these devices used a GUI toolkit that provided StickyKeys like
functionality?

You also ask:

> What is so special about OSs versus application software or websites? How
> could it be "wrong" to require OSs, but not apps and sites, to have certain
> accessibility features?

There are some subtle differences which may be relevant. Apps run on a
platform (generally an OS). While there are multi-platform apps, they
are either running inside some sort of virtual machine (e.g. the Java
runtime environment), or they have some amount of platform-dependent
code that manages the OS-specific parts [putting the menu bar at the top
of the screen on Macintosh, vs. at the top of the window on Windows].
By contrast, web documents, like many documents, have to run on some of
the widest ranges of places. And many web documents and other documents
don't themselves contain code - though some are driven by code (e.g. a
program on a server serving up pages). Those that do contain actual
code - Javascript, Flash, Java applets, AJAX - are I think more properly
seen as applications.

In any case, I think for any given "platform", one can reasonably draw a
line separating accessibility responsibility between the OS and the apps
on that OS. I think today we find that Window, Macintosh, and graphical
UNIX are all moving to draw that line in the same basic place: with the
OS providing a significant number of services to support accessibility
on the platform overall [including the StickyKeys family of tools, some
AT, an accessibility API/framework for app+AT communication]. But is
this the right place for things to converge on a phone with an OS that
runs apps? Maybe. But maybe not.

In contrast, with something like a static document, all the information
that is needed for accessibility must be contained within that document,
or referenced from that document, or otherwise available to the app
within which the document is being used. When the document becomes an
application - an AJAX based web-app for example - then I think we need
to shift to the application rules, but with the additional twist that
the app player becomes a "platform within a platform", and perhaps has
some additional, special responsibilities.


I hope I've managed to answer your questions, and not simply muddy the
waters further...


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


>> -----Original Message-----
>> From: Peter Korn [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Thursday, October 19, 2006 1:53 PM
>> To: TEITAC Web/Software Subcommittee
>> Subject: [teitac-websoftware] 1194.22(b) in Group A: Re: Jim
>> Tobias' commentabout requiring AT
>>
>> Jim's comment on 1194.22(b) is:
>>
>> 'Jim Tobias: Going beyond this provision, how about requiring
>> operating systems to include certain accessibility features?
>> The major operating systems do have such features. The list
>> of required features would have to be decided upon, and even
>> more difficult, an agreement as to what constitutes an
>> "operating system".'
>>
>> I am a bit concerned with this. While I'm delighted to see
>> what appears to be actual competition among OS vendors in
>> bundling AT with their OSes (as we now have competition in
>> car manufacturers as to how may air bags they have), I do not
>> think we should require that. I think it is wrong to place a
>> barrier to entry in the OS market saying that you have to
>> provide specific AT with your OS, or specific "accessibility
>> features".
>>
>
> What is so special about OSs versus application software or websites? How
> could it be "wrong" to require OSs, but not apps and sites, to have certain
> accessibility features? You may have thought I meant screen readers; I
> didn't. I intended us to consider creating a floor for OSs, so that all
> future versions would have to have the same kinds of features they have now,
> like StickyKeys, etc. Otherwise we risk an unlevel playing field indeed.
> Suppose that someone comes up with a really stripped-down OS that can run
> the apps an agency needs, but the OS has no accessibility features. Under
> the current regs, the app complies with the "do not disrupt" provision, but
> since there's nothing in the OS, the user cannot access the app. My
> proposal would eliminate the current lack of accessibility requirements for
> OSs.
>
>
>> I believe we should have outcomes-based requirements (e.g. "a
>> user must be able to operate all keyboard functions with a
>> single keypress"), and then recommend specific guidance as to
>> how to accomplish thing (e.g.
>> "cf. StickyKeys capabilities for latching keyboard
>> modifiers"), and the finally ensure that we don't foreclose
>> innovation (by maintaining 1194.5 Equivalent facilitation
>> "Nothing in this part is intended to prevent the use of
>> designs or technologies as alternatives to those prescribed
>> in this part provided they result in substantially equivalent
>> or greater access to and use of a product for people with
>> disabilities.").
>>
>> I would not explicitly require in 508 that all OSes must
>> include StickyKeys, even though the three most popular
>> desktops (Windows, Mac, UNIX) already do.
>>
>
> I'm not sure I really understand your position. Let me try to rephrase what
> you've written. Assuming the equivalent facilitation language, would you
> support language that says "the operating system must allow a user to
> operate all keyboard functions with a single keypress"? If not, why not?
>
>
>

From: Gani, Dewi
Date: Fri, Oct 20 2006 5:10 AM
Subject: Re: 1194.22(b) in Group A: Re: Peter Korn'scomment about StickyKeys

Peter's comment on:

'I would not explicitly require in 508 that all OSes must include
StickyKeys, even though the three most popular desktops (Windows, Mac,
UNIX) already do.'

To make the user's life easier, I would suggest to have a global setting
in this case. Thus, I think Oses shall provide this StickyKeys feature
and I propose to have this information mentioned in Section 508.

Best Regards,

Dewi Gani


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Korn
Sent: Donnerstag, 19. Oktober 2006 19:53
To: TEITAC Web/Software Subcommittee
Subject: [teitac-websoftware] 1194.22(b) in Group A: Re: Jim Tobias'
commentabout requiring AT

Jim's comment on 1194.22(b) is:

'Jim Tobias: Going beyond this provision, how about requiring
operating systems to include certain accessibility features? The major
operating systems do have such features. The list of required features
would
have to be decided upon, and even more difficult, an agreement as to
what
constitutes an "operating system".'

I am a bit concerned with this. While I'm delighted to see what appears

to be actual competition among OS vendors in bundling AT with their OSes

(as we now have competition in car manufacturers as to how may air bags
they have), I do not think we should require that. I think it is wrong
to place a barrier to entry in the OS market saying that you have to
provide specific AT with your OS, or specific "accessibility features".

I believe we should have outcomes-based requirements (e.g. "a user must
be able to operate all keyboard functions with a single keypress"), and
then recommend specific guidance as to how to accomplish thing (e.g.
"cf. StickyKeys capabilities for latching keyboard modifiers"), and the
finally ensure that we don't foreclose innovation (by maintaining 1194.5

Equivalent facilitation "Nothing in this part is intended to prevent the

use of designs or technologies as alternatives to those prescribed in
this part provided they result in substantially equivalent or greater
access to and use of a product for people with disabilities.").

I would not explicitly require in 508 that all OSes must include
StickyKeys, even though the three most popular desktops (Windows, Mac,
UNIX) already do.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

From: Sailesh Panchang
Date: Fri, Oct 20 2006 8:25 AM
Subject: Re: 1194.22(b) in Group A:Distinguish OS fromsoftware apps and Web content

I wonder if it makes sense to have one set of standards for operating
systems and another that covers software apps and Web content / Web apps?
Sailesh Panchang
Senior Accessibility Engineer
Deque Systems Inc. (www.deque.com)
11130 Sunrise Valley Drive, Suite #140,
Reston VA 20191
Phone: 703-225-0380 (ext 105)
E-mail: = EMAIL ADDRESS REMOVED =

From: Roberto Scano (IWA/HWG)
Date: Fri, Oct 20 2006 8:35 AM
Subject: Re: 1194.22(b) in Group A:Distinguish OSfromsoftware apps and Web content

----- Messaggio originale -----
Da: "Sailesh Panchang"< = EMAIL ADDRESS REMOVED = >

I wonder if it makes sense to have one set of standards for operating
systems and another that covers software apps and Web content / Web apps?

Roberto Scano:
I suggest to follow iso: one set for os and applications and another one for web user interfaces (iso 9241-171 and iso 9241-151).
There are then some principle for os, other for software, other that could be applicable to both.

From: Andrew Kirkpatrick
Date: Fri, Oct 20 2006 9:35 AM
Subject: Re: 1194.22(b) in Group A:DistinguishOSfromsoftware apps and Web content

> I suggest to follow iso: one set for os and applications and
> another one for web user interfaces (iso 9241-171 and iso 9241-151).
> There are then some principle for os, other for software,
> other that could be applicable to both.

This is one of the chief issues that we need to address, in my opinion.
What is an "application" and what is a "web user interface". There is
not a clean distinction drawn between these in most people's minds, and
this is problematic for compliance.

Roberto, when you say "some would be applicable to both" do you mean
both ="software and OS" or both="software and web"?

AWK

From: Gregg Vanderheiden
Date: Fri, Oct 20 2006 9:55 AM
Subject: Re: 1194.22(b) in Group A:Distinguish OSfromsoftware apps and Web content

I think we will end up with

- some guidelines that apply across all three (and I do believe you will
need to talk about ROLES again. A browser looks like an application and a
platform. And software can be in all three roles.

- some guidelines or specifics that apply to just one role of software/docs.


Are we talking about soft-plat-web-doc ??

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sailesh
Panchang
Sent: Friday, October 20, 2006 9:23 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] 1194.22(b) in Group A:Distinguish OS
fromsoftware apps and Web content

I wonder if it makes sense to have one set of standards for operating
systems and another that covers software apps and Web content / Web apps?
Sailesh Panchang
Senior Accessibility Engineer
Deque Systems Inc. (www.deque.com)
11130 Sunrise Valley Drive, Suite #140,
Reston VA 20191
Phone: 703-225-0380 (ext 105)
E-mail: = EMAIL ADDRESS REMOVED =

From: Roberto Scano (IWA/HWG)
Date: Fri, Oct 20 2006 10:00 AM
Subject: Re: 1194.22(b) in GroupA:DistinguishOSfromsoftware apps and Web content

----- Messaggio originale -----
Da: "Andrew Kirkpatrick"< = EMAIL ADDRESS REMOVED = >
Inviato: 20/10/06 17.30.10
A: "TEITAC Web/Software Subcommittee"< = EMAIL ADDRESS REMOVED = >
This is one of the chief issues that we need to address, in my opinion.
What is an "application" and what is a "web user interface". There is
not a clean distinction drawn between these in most people's minds, and
this is problematic for compliance.

Roberto Scano:
i agree wuth you, but we need to think also using an international view, and ISO working group involves experts worldwide.
Think that the same difference causes different evalutation in w3c atag 2.0 (www.w3.org/tr/atag20) where web-based authoring tools (WCMS, etc.) have a relative priority referred to WCAG.
Some issues in software interfaces could be similar with in web (eg. Text resizing, keyboard access, ...) other are specific of application (hereditate os user preferences for menu, text, ...) other are os specific (stiky keys, audio alerts, ...)
Andrew Kirkpatrick:
Roberto, when you say "some would be applicable to both" do you mean
both ="software and OS" or both="software and web"?

Roberto:
Software and os

From: Luke Kowalski
Date: Fri, Oct 20 2006 11:25 AM
Subject: Re: 1194.22(b) in Group A:Distinguish OSfromsoftware apps and Web content

-----Original Message-----
[GregV said ]I think we will end up with

- some guidelines that apply across all three (and I do believe you will need to talk about ROLES again. A browser looks like an application and a platform. And software can be in all three roles.

- some guidelines or specifics that apply to just one role of software/docs.


Are we talking about soft-plat-web-doc ??

---------------------------
Indeed. Classifications that are technology-specific are usually trouble. Let us take a new breed of applications coming from Google, Adobe, and Oracle. They are little AJAX apps that run on the desktop. They look and feel like rich desktop apps (drag and drop, no refreshes or roud trips to the server), but they actually talk to web services via HTTP. Do they fall into the browser or desktop app category? Neither...
Overarching (general) and OS specific categories are maybe workable, but the web and the desktop are blending, which is why, to Robertos' point, you are seeing some overlap between ISO 9241 151 and 171.


luke kowalski, CPE
Corporate UI Architect
http://ui.oracle.com
Redwood Shores, CA 94065
650 506 1227

From: Li, Alex
Date: Fri, Oct 20 2006 3:40 PM
Subject: Re: 1194.22(b) in Group A:Distinguish OS fromsoftware apps

Hi all,

Just want to remind the group the rationale to review 1194.21 and
1194.22 together is that much of what needs to be done is similar
whether it is a web-based application and desktop application and that
many experts who work on web accessibility also work on desktop
application accessibility. But it would be wise to keep 1194.21 and
1194.22 separate because 1) there are still some difference between web
applications and desktop applications, 2) there are still many simple
government websites that would not fit so well with application
standards, and, 3) most importantly, no existing accessibility standard
has yet to consolidate the requirements of desktop applications and web
applications. Trying to consolidate 1194.21 and 1194.22 would require
significant investment in time, effort, and expertise in order to invent
something new. Given the timeline of TEITAC, it would be very difficult
to do so. Also, we should try to harmonize with other standards and
guidelines such as WCAG 2.0. Merging 1194.21 and 1194.22 would blow our
harmonization theme/objective out of the water. This same argument also
applies to the idea of trying to separate OS requirements from desktop
applications requirements. Trying to make the separation would get us
into trouble with harmonization and require extraordinary effort to
determine what OS should and should not do.

All best,

Alex Li
Manager, Accessibility Standards and Policies
SAP Labs, Inc.
3410 Hillview Ave
Palo Alto, CA 94304
T (650) 687-4770
F (610) 492-2961
M (202) 492-4592
mailto: = EMAIL ADDRESS REMOVED =
http://www.sap.com <http://www.sap.com/>
THE BEST-RUN BUSINESSES RUN SAP
This e-mail is confidential and may contain privileged information. If
you are not the addressee it may be unlawful for you to read, copy,
distribute, disclose or otherwise use the information in this e-mail. If
you are not the intended recipient please notify us immediately.

From: Travis Roth
Date: Fri, Oct 20 2006 5:35 PM
Subject: Re: 1194.22(b) in Group A:Distinguish OSfromsoftware apps

Alex Li wrote:
"there are still many simple government websites that would not fit so well
with application standards"

It would seem logical to have some separation between web applications and
content. Some websites are content-oriented whereas others are applications.

Also the line between software and web applications is blurring. While
keeping the guidelines separate for now may be most logical, I anticipate
many of the guidelines will overlap as the current trend is for web
applications to simulate the functionality formerly only found in software
applications.

--
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.

From: Brett, Thomas F
Date: Sat, Oct 21 2006 6:40 AM
Subject: Re: 1194.22(b) in Group A:DistinguishOSfromsoftware apps

I agree that there are many Government sites that are relatively simple but there are many more that are moving beyond just content. The eGov Act of 2002 requires more and more of an agency's data be made available in electronic format. This is being mandated by OMB Policy. Methods of making this data available to the public is no longer limited to straight HTML.

There was discussion on one of the open Government List servs-ISD508WG-last spring about combining 1194.21 & 1194.22. The consensus was that they should be combined.


Tom Brett

From: RAJIV SHAH
Date: Sat, Oct 21 2006 12:15 PM
Subject: Re: 1194.22(b) in Group A:Distinguish OS fromsoftware apps

Travis Roth Wrote:
> Also the line between software and web applications is > blurring. While keeping the guidelines separate for now may > > be most logical, I anticipate many of
the guidelines will overlap as the current trend is for web > applications to simulate the functionality formerly only > found in software applications.
Rajiv Shah Response:
Travis, I couldn't agree with you more, especially with increasingly sophisticated JavaScript events being used to mimic software functionality via Web-based apps. I used a Web-based calculator several days back which I could have only imagined as a software application two years ago.

Regards,

Rajiv

From: Li, Alex
Date: Mon, Oct 23 2006 9:25 AM
Subject: Re: 1194.22(b) in Group A:Distinguish OSfromsoftware apps

It is clear that web applications are getting more prevalent. But that
does not necessarily mean we have to merge 1194.21 and 1194.22. Note
that the WCAG 2.0 draft accommodates both web applications and "simple
websites". It would make sense, for the interest of efficiency and
harmonization, to update 1194.22 to handle both web applications and
websites. It is obvious that there will be a lot of parallel between
1194.21 and 1194.22 after we are done. All I'm trying to say
is--attempting such consolidation would be a lot of work and create
harmonization problem.

All best,
Alex Li
Manager, Accessibility Standards and Policies
SAP Labs, Inc.
3410 Hillview Ave
Palo Alto, CA 94304
T (650) 687-4770
F (610) 492-2961
M (202) 492-4592
mailto: = EMAIL ADDRESS REMOVED =
http://www.sap.com <http://www.sap.com/>
THE BEST-RUN BUSINESSES RUN SAP
This e-mail is confidential and may contain privileged information. If
you are not the addressee it may be unlawful for you to read, copy,
distribute, disclose or otherwise use the information in this e-mail. If
you are not the intended recipient please notify us immediately.

From: Michael R. Burks
Date: Mon, Oct 23 2006 9:35 AM
Subject: Re: 1194.22(b) in Group A:DistinguishOSfromsoftware apps

It is clear that web applications are getting more prevalent. But that does
not necessarily mean we have to merge 1194.21 and 1194.22. Note that the
WCAG 2.0 draft accommodates both web applications and "simple websites". It
would make sense, for the interest of efficiency and harmonization, to
update 1194.22 to handle both web applications and websites. It is obvious
that there will be a lot of parallel between 1194.21 and 1194.22 after we
are done. All I'm trying to say is--attempting such consolidation would be
a lot of work and create harmonization problem.

I would like to see a clear definition of "Harmonization" is there such a
definition?



Mike Burks

919 870 8788 - Office

703-254-3881 - Cell

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Li, Alex
Sent: Monday, October 23, 2006 11:20 AM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-websoftware] 1194.22(b) in Group A:Distinguish
OSfromsoftware apps



It is clear that web applications are getting more prevalent. But that does
not necessarily mean we have to merge 1194.21 and 1194.22. Note that the
WCAG 2.0 draft accommodates both web applications and "simple websites". It
would make sense, for the interest of efficiency and harmonization, to
update 1194.22 to handle both web applications and websites. It is obvious
that there will be a lot of parallel between 1194.21 and 1194.22 after we
are done. All I'm trying to say is--attempting such consolidation would be
a lot of work and create harmonization problem.

All best,
Alex Li
Manager, Accessibility Standards and Policies
SAP Labs, Inc.
3410 Hillview Ave
Palo Alto, CA 94304
T (650) 687-4770
F (610) 492-2961
M (202) 492-4592
mailto: <mailto: = EMAIL ADDRESS REMOVED = > = EMAIL ADDRESS REMOVED =
<http://www.sap.com/> http://www.sap.com
THE BEST-RUN BUSINESSES RUN SAP
This e-mail is confidential and may contain privileged information. If you
are not the addressee it may be unlawful for you to read, copy, distribute,
disclose or otherwise use the information in this e-mail. If you are not the
intended recipient please notify us immediately.

From: Jessica M. Brodey
Date: Mon, Oct 23 2006 9:40 AM
Subject: Re: 1194.22(b) in Group A:DistinguishOSfromsoftware apps

<ALEX LI SAID> "It is clear that web applications are getting more
prevalent. But that does not necessarily mean we have to merge 1194.21 and
1194.22. Note that the WCAG 2.0 draft accommodates both web applications
and "simple websites". It would make sense, for the interest of efficiency
and harmonization, to update 1194.22 to handle both web applications and
websites. It is obvious that there will be a lot of parallel between
1194.21 and 1194.22 after we are done. All I'm trying to say is--attempting
such consolidation would be a lot of work and create harmonization problem."

This approach seems to make sense - we just have to be careful that in
accommodating web applications and simple websites in 1194.22 that we do not
cause a conflict in standards for those that would fall under both 1194.21
and 1194.22 by having inconsistent/differing standards. It is not usually a
problem to duplicate standards in both places, but if one segment has
requirements that the other does not, for those technologies that could
arguable fall under one or the other, there becomes a fight to fit under the
classification that allows them to do the least amount to satisfy the
accessibility requirements. This is something we should obviously try and
avoid.

Jessica

From: Li, Alex
Date: Mon, Oct 23 2006 10:40 AM
Subject: Re: 1194.22(b) in Group A:Distinguish OSfromsoftware apps

>I would like to see a clear definition of "Harmonization" is there such
a definition?

Harmonization is one of the themes of the TEITAC. But it was not
defined at the TEITAC meeting. Most of you should be very aware of WCAG
2.0, which applies to web content including websites and web apps. The
existing 1194.22 is somewhat similar to WCAG 1.0. Ideally, websites and
web apps that meet the requirements in 1194.22 should also meet a
particular level of WCAG 2.0 guidelines. Once 1194.21 and 1194.22
become one, it would be difficult, if not impossible, for any given
website or web app to meet both sets of requirements. In the best case
scenario, the developer would have to jump through a lot of hoops to
figure out the difference between the two and determine what needs to be
done to accommodate one or the other. Opportunity for error of
interpretation would be very high. Merging 1194.21 and 1194.22 would
not only take a lot of work from TEITAC, it would also take a lot of
work from government agencies and vendors to interpret. It would also
seriously disrupt the development and acceptance of WCAG 2.0. Doing so
would certainly not be anybody's definition of harmonization. This line
of thinking goes the same for software accessibility standards such as
ISO 9241-171.

It is far easier to duplicate requirements in 1194.21 and 1194.22 then
to merge the two into one. Let's try to keep things simple.

From: Luke Kowalski
Date: Mon, Oct 23 2006 10:50 AM
Subject: Re: 1194.22(b) in Group A:Distinguish OSfromsoftware apps

[Alex Li wrote] It is far easier to duplicate requirements in 1194.21 and 1194.22 then to merge the two into one. Let's try to keep things simple.

I was making the same point earlier. Trying to introduce a merged standard will introduce more problems that it will solve (despite the fact that the web and desktop lines are starting to blurr).

My definition of harmonization is that coordination makes things more relevant and actionable for every one of the participants. It also makes things less confusing for people trying to abide by the guidelines and help users who face challenges.

luke kowalski, CPE
Corporate UI Architect
http://ui.oracle.com
Redwood Shores, CA 94065
650 506 1227

From: Michael R. Burks
Date: Mon, Oct 23 2006 11:05 AM
Subject: Re: 1194.22(b) in Group A:DistinguishOSfromsoftware apps

>I would like to see a clear definition of "Harmonization" is there such a
definition?

Harmonization is one of the themes of the TEITAC. But it was not defined at
the TEITAC meeting. Most of you should be very aware of WCAG 2.0, which
applies to web content including websites and web apps. The existing
1194.22 is somewhat similar to WCAG 1.0. Ideally, websites and web apps that
meet the requirements in 1194.22 should also meet a particular level of WCAG
2.0 guidelines. Once 1194.21 and 1194.22 become one, it would be difficult,
if not impossible, for any given website or web app to meet both sets of
requirements. In the best case scenario, the developer would have to jump
through a lot of hoops to figure out the difference between the two and
determine what needs to be done to accommodate one or the other.
Opportunity for error of interpretation would be very high. Merging 1194.21
and 1194.22 would not only take a lot of work from TEITAC, it would also
take a lot of work from government agencies and vendors to interpret. It
would also seriously disrupt the development and acceptance of WCAG 2.0.
Doing so would certainly not be anybody's definition of harmonization. This
line of thinking goes the same for software accessibility standards such as
ISO 9241-171.

It is far easier to duplicate requirements in 1194.21 and 1194.22 then to
merge the two into one. Let's try to keep things simple.

Two Items,



1. This did not answer the question as to what the definition of
Harmonization is.
2. I think it is best to leave WCAG 2.0 out of this discussion for the
moment as least as far as being a standard to follow. It is not a standard,
and there are still many, many issues with WCAG 2.0



Sincerely,

Mike Burks

919 870 8788 - Office

703-254-3881 - Cell

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Li, Alex
Sent: Monday, October 23, 2006 12:36 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-websoftware] 1194.22(b) in Group A:Distinguish
OSfromsoftware apps





>I would like to see a clear definition of "Harmonization" is there such a
definition?

Harmonization is one of the themes of the TEITAC. But it was not defined at
the TEITAC meeting. Most of you should be very aware of WCAG 2.0, which
applies to web content including websites and web apps. The existing
1194.22 is somewhat similar to WCAG 1.0. Ideally, websites and web apps that
meet the requirements in 1194.22 should also meet a particular level of WCAG
2.0 guidelines. Once 1194.21 and 1194.22 become one, it would be difficult,
if not impossible, for any given website or web app to meet both sets of
requirements. In the best case scenario, the developer would have to jump
through a lot of hoops to figure out the difference between the two and
determine what needs to be done to accommodate one or the other.
Opportunity for error of interpretation would be very high. Merging 1194.21
and 1194.22 would not only take a lot of work from TEITAC, it would also
take a lot of work from government agencies and vendors to interpret. It
would also seriously disrupt the development and acceptance of WCAG 2.0.
Doing so would certainly not be anybody's definition of harmonization. This
line of thinking goes the same for software accessibility standards such as
ISO 9241-171.

It is far easier to duplicate requirements in 1194.21 and 1194.22 then to
merge the two into one. Let's try to keep things simple.

From: Brett, Thomas F
Date: Mon, Oct 23 2006 11:20 AM
Subject: Re: 1194.22(b) in GroupA:DistinguishOSfromsoftware apps

I would like to see a clear definition of "Harmonization" is there such
a definition?



I agree with Michael...I believe that we will need to define what is
meant by harmonization or at least for this subcommittee.



Tom Brett,

Section 508 Coordinator

US Office of Personnel Management

Rm 6H34A

2026061206 (v)

2026062582 (tty)

Disabled does not mean Unable

= EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Michael
R. Burks
Sent: Monday, October 23, 2006 11:31 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] 1194.22(b) in Group
A:DistinguishOSfromsoftware apps



It is clear that web applications are getting more prevalent. But that
does not necessarily mean we have to merge 1194.21 and 1194.22. Note
that the WCAG 2.0 draft accommodates both web applications and "simple
websites". It would make sense, for the interest of efficiency and
harmonization, to update 1194.22 to handle both web applications and
websites. It is obvious that there will be a lot of parallel between
1194.21 and 1194.22 after we are done. All I'm trying to say
is--attempting such consolidation would be a lot of work and create
harmonization problem.

I would like to see a clear definition of "Harmonization" is there such
a definition?



Mike Burks

919 870 8788 - Office

703-254-3881 - Cell

From: Gregg Vanderheiden
Date: Mon, Oct 23 2006 11:35 AM
Subject: Re: 1194.22(b) in Group A:DistinguishOSfromsoftware apps

I think the most common one is that they do not interfere with each other.
That you can meet both (all) of them at the same time.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Li, Alex
Sent: Monday, October 23, 2006 11:36 AM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-websoftware] 1194.22(b) in Group A:Distinguish
OSfromsoftware apps



>I would like to see a clear definition of "Harmonization" is there such a
definition?

Harmonization is one of the themes of the TEITAC. But it was not defined at
the TEITAC meeting. Most of you should be very aware of WCAG 2.0, which
applies to web content including websites and web apps. The existing
1194.22 is somewhat similar to WCAG 1.0. Ideally, websites and web apps that
meet the requirements in 1194.22 should also meet a particular level of WCAG
2.0 guidelines. Once 1194.21 and 1194.22 become one, it would be difficult,
if not impossible, for any given website or web app to meet both sets of
requirements. In the best case scenario, the developer would have to jump
through a lot of hoops to figure out the difference between the two and
determine what needs to be done to accommodate one or the other.
Opportunity for error of interpretation would be very high. Merging 1194.21
and 1194.22 would not only take a lot of work from TEITAC, it would also
take a lot of work from government agencies and vendors to interpret. It
would also seriously disrupt the development and acceptance of WCAG 2.0.
Doing so would certainly not be anybody's definition of harmonization. This
line of thinking goes the same for software accessibility standards such as
ISO 9241-171.

It is far easier to duplicate requirements in 1194.21 and 1194.22 then to
merge the two into one. Let's try to keep things simple.

From: Gregg Vanderheiden
Date: Mon, Oct 23 2006 11:40 AM
Subject: Re: 1194.22(b) in Group A:DistinguishOSfromsoftware apps

This looks reasonable.



Remember that telecom devices also have application software and platform
software. So those concepts will flow everywhere. If we want to combine
them all we will end up with just one category.



Part of what we will be looking at in the General group will be "what
applies to all". Your thoughts on this are sought. We don't want to
duplicate this discussion but rather refer to it. So you might also think
about what aspects are common and what are specific to a technology area.
Software clearly will be everywhere. And we want harmonization starting
within our own guidelines... (grin).




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Li, Alex
Sent: Monday, October 23, 2006 10:20 AM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-websoftware] 1194.22(b) in Group A:Distinguish
OSfromsoftware apps

It is clear that web applications are getting more prevalent. But that does
not necessarily mean we have to merge 1194.21 and 1194.22. Note that the
WCAG 2.0 draft accommodates both web applications and "simple websites". It
would make sense, for the interest of efficiency and harmonization, to
update 1194.22 to handle both web applications and websites. It is obvious
that there will be a lot of parallel between 1194.21 and 1194.22 after we
are done. All I'm trying to say is--attempting such consolidation would be
a lot of work and create harmonization problem.

All best,
Alex Li
Manager, Accessibility Standards and Policies
SAP Labs, Inc.
3410 Hillview Ave
Palo Alto, CA 94304
T (650) 687-4770
F (610) 492-2961
M (202) 492-4592
mailto: <mailto: = EMAIL ADDRESS REMOVED = > = EMAIL ADDRESS REMOVED =
<http://www.sap.com/> http://www.sap.com
THE BEST-RUN BUSINESSES RUN SAP
This e-mail is confidential and may contain privileged information. If you
are not the addressee it may be unlawful for you to read, copy, distribute,
disclose or otherwise use the information in this e-mail. If you are not the
intended recipient please notify us immediately.

From: Sailesh Panchang
Date: Tue, Oct 24 2006 10:25 AM
Subject: Re: 1194.22(b) in Group A:Distinguish OS fromsoftware apps

Although I have no doubt that the updated standards will continue to state
that "(a) Products covered by this part shall comply with all applicable
provisions of this part." (Ref: 1194.2 Application), I'd like to point out
that people had reservations in applying certain paragraphs of .21 while
evaluating Web apps.

So consider three groups for the new standards labeled as follows:

1. Mainly applying to platform software

2. Mainly applying to software applications

3. Mainly applying to Web content and Web applications



I think Alex Lee argues strongly in maintaining the distinction between .21
and .22 and I support this especially given the timeline for the refresh
initiative. Yet it may be possible to separate the requirements for
platform/OS



The S508 standards lay down a minimum threshold and do not incorporate the
best practice. So we should remember the 80:20 rule and not let possible but
unlikely inaccessibility scenarios impede the refresh progress.



Sailesh Panchang
Senior Accessibility Engineer
Deque Systems Inc. (www.deque.com)
11130 Sunrise Valley Drive, Suite #140,
Reston VA 20191
Phone: 703-225-0380 (ext 105)
E-mail: = EMAIL ADDRESS REMOVED =

_____