Thread Subject: Re: Group A distinguishing

Return to this mailing list's archives

From: Michael R. Burks
Date: Mon, Oct 23 2006 10:55 AM
Subject: Re: Group A distinguishing

Currently:

1194.21(a): Keyboard accessibility. Poster child and most wanted in web.



Can be rewritten to include many categories, for example



(all): When EIT is designed to use a keyboard as a means of (insert
functionality), (insert keyboard accessibility requirements here). I left
blanks here on purpose to not define all the categories right now and start
any debate there, nor the specific set of actual keyboard requirements
either. I just want to float this scoping concept for any thoughts you all
may have. i think it might lend some clarity to how to approach software,
web, and content requirements.



I agree with Al. This looks like the best way to do this.



Mike Burks

919 870 8788 - Office

703-254-3881 - Cell

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Hoffman,
Allen
Sent: Monday, October 23, 2006 12:28 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Group A distinguishing



all:



here are some thoughts regarding how we might think about scoping of
requirements. We will have to work through this challenge, and if we can
find a common approach for all maybe that would expedite this process.



As I'm sure the general subcommittee is discussing, there are a set of core
requirements that can be applied across the board. then there are
requirements that apply to subsets of all. If we label each standard with
the scope it applies to, then this can be a much simpler process.



for example:



Currently:

1194.21(a): Keyboard accessibility. Poster child and most wanted in web.



Can be rewritten to include many categories, for example



(all): When EIT is designed to use a keyboard as a means of (insert
functionality), (insert keyboard accessibility requirements here). I left
blanks here on purpose to not define all the categories right now and start
any debate there, nor the specific set of actual keyboard requirements
either. I just want to float this scoping concept for any thoughts you all
may have. i think it might lend some clarity to how to approach software,
web, and content requirements.



Allen Hoffman

Department of homeland Security

Office On Accessible Systems & Technology

v: 202-447-0303 office-TTY: 202-401-0725

From: Hoffman, Allen
Date: Mon, Oct 23 2006 11:10 AM
Subject: Re: Group A distinguishing

all:

here are some thoughts regarding how we might think about scoping of
requirements. We will have to work through this challenge, and if we
can find a common approach for all maybe that would expedite this
process.

As I'm sure the general subcommittee is discussing, there are a set of
core requirements that can be applied across the board. then there are
requirements that apply to subsets of all. If we label each standard
with the scope it applies to, then this can be a much simpler process.

for example:

Currently:
1194.21(a): Keyboard accessibility. Poster child and most wanted in
web.

Can be rewritten to include many categories, for example

(all): When EIT is designed to use a keyboard as a means of (insert
functionality), (insert keyboard accessibility requirements here). I
left blanks here on purpose to not define all the categories right now
and start any debate there, nor the specific set of actual keyboard
requirements either. I just want to float this scoping concept for any
thoughts you all may have. i think it might lend some clarity to how to
approach software, web, and content requirements.

Allen Hoffman
Department of homeland Security
Office On Accessible Systems & Technology
v: 202-447-0303 office-TTY: 202-401-0725

From: Barrett, Don
Date: Mon, Oct 23 2006 2:35 PM
Subject: Re: Group A distinguishing

What I like about Al's approach is that it keeps discussion focused on
functional constructs rather than theoretical ones. In our practical
day-to-day application of 508, we have seen that it is the functional
standards which provide the greatest and most consistent level of
accessibility. That's why conformance to the web standards has been
traditionally easier to test for than conformance to the software
standards. Constructs like sufficient information being exposed by
interface elements, or textual information being written through the OS
though relevant are hard to test for, and the more functional approach
engendered by the web standards lends itself to a greater level of
validity and reliability.

Whatever we come up with, let's please keep measurability in mind as
much as is feasible.

From: Gregg Vanderheiden
Date: Mon, Oct 23 2006 3:40 PM
Subject: Group A distinguishing

FYI


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

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Michael R.
Burks
Sent: Monday, October 23, 2006 11:54 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Group A distinguishing



Currently:

1194.21(a): Keyboard accessibility. Poster child and most wanted in web.



Can be rewritten to include many categories, for example



(all): When EIT is designed to use a keyboard as a means of (insert
functionality), (insert keyboard accessibility requirements here). I left
blanks here on purpose to not define all the categories right now and start
any debate there, nor the specific set of actual keyboard requirements
either. I just want to float this scoping concept for any thoughts you all
may have. i think it might lend some clarity to how to approach software,
web, and content requirements.



I agree with Al. This looks like the best way to do this.



Mike Burks

919 870 8788 - Office

703-254-3881 - Cell

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Hoffman,
Allen
Sent: Monday, October 23, 2006 12:28 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Group A distinguishing



all:



here are some thoughts regarding how we might think about scoping of
requirements. We will have to work through this challenge, and if we can
find a common approach for all maybe that would expedite this process.



As I'm sure the general subcommittee is discussing, there are a set of core
requirements that can be applied across the board. then there are
requirements that apply to subsets of all. If we label each standard with
the scope it applies to, then this can be a much simpler process.



for example:



Currently:

1194.21(a): Keyboard accessibility. Poster child and most wanted in web.



Can be rewritten to include many categories, for example



(all): When EIT is designed to use a keyboard as a means of (insert
functionality), (insert keyboard accessibility requirements here). I left
blanks here on purpose to not define all the categories right now and start
any debate there, nor the specific set of actual keyboard requirements
either. I just want to float this scoping concept for any thoughts you all
may have. i think it might lend some clarity to how to approach software,
web, and content requirements.



Allen Hoffman

Department of homeland Security

Office On Accessible Systems & Technology

v: 202-447-0303 office-TTY: 202-401-0725

From: Jim Thatcher
Date: Mon, Oct 23 2006 4:40 PM
Subject: Re: Group A distinguishing

Don Barrett said in part:
<blockquote>
What I like about Al's approach is that it keeps discussion focused on
functional constructs rather than theoretical ones.  ? That's why
conformance to the web standards has been traditionally easier to test for
than conformance to the software standards.  Constructs like sufficient
information being exposed by interface elements, ?
</blockquote>

I think I agree with you and Al, but I worry about the terminology you used
here, Don. The phrase ?functional constructs? raises the issue of the
?functional standards? (1194.31) for which conformance is most difficult. So
maybe we don?t agree ? let?s see.

I am not sure which word to substitute for functional, but ?testable? is a
consequence. The 508 standards for web and for software include provisions
that are not testable, like ?Sufficient information about a user interface
element including ?? and ?a variety of color selections capable of producing
a range of contrast levels shall be provided? in 1194.21 (software) and ?the
form shall allow people using assistive technology to access the
information? and ?readable without requiring an associated style sheet? in
1194.22 (web).

I think what we want is testable (not necessarily machine testable)
statements. With that as a premise, I have no problem having identical
provisions in software and web, which can end up being in a common set. So
for example both software and web could have standards like the following
modified from WCAG 2.0 and encompassing 1194.21(d):

For all user interface components, the name, role and state can be
programmatically determined, values that can be set by the user can be
programmatically set, and notification of changes to these items is
available to user agents, including assistive technologies. (Several words
and phrases need definitions here, but those are available.)

It is specific, testable, and, as it turns out, is applicable to both
software and web. The fact that it is applicable to both is good news, but,
I think, a conclusion to be drawn later in our process.

Jim
 
Accessibility Consulting: http://jimthatcher.com/
512-306-0931

From: Andrew Kirkpatrick
Date: Mon, Oct 23 2006 6:35 PM
Subject: Re: Group A distinguishing

> For all user interface components, the name, role and
> state can be programmatically determined, values that can be
> set by the user can be programmatically set, and notification
> of changes to these items is available to user agents,
> including assistive technologies. (Several words and phrases
> need definitions here, but those are available.)

I agree with this general idea, Jim. I suspect that many people will be
concerned that this standard would replace several current 1194.22
standards (specifically, this would encompass 22a, f, g, h, I, and l,
possibly o also).

I like this approach since as we start to see more than a few simple
controls in "web" documents and applications the set of standards that
currently exist in 22 are increasingly too specific to cover the needs
that are present in these applications.

Are people comfortable with the idea of taking a standard like 22g (Row
and Column headers...) out of 22 since it is covered by a standard like
what Jim proposes above? For the record, I am.

AWK

From: Jonathan Avila
Date: Mon, Oct 23 2006 6:40 PM
Subject: Re: Group A distinguishing

> For all user interface components, the name, role and state can
> be programmatically determined, values that can be set by the user can
> be programmatically set, and notification of changes to these items is
> available to user agents, including assistive technologies. (Several
> words and phrases need definitions here, but those are available.)

[my additions] I think values should be added to the same list as name,
role, and state, access to read only values is critical to people who are
blind or visually impaired, thus all values are important and no just user
changeable ones.

Jonathan

From: Jim Thatcher
Date: Mon, Oct 23 2006 7:55 PM
Subject: Re: Group A distinguishing

I reluctantly continue here with the same subject only to say that I totally
disagree with Andrew (with whom I usually totally agree) - in this

> I suspect that many people will be concerned that this standard would
> replace several current 1194.22 standards (specifically, this would
> encompass 22a, f, g, h, I, and l, possibly o also).

I think only l (scripting) might fall under the interface elements
requirement I mentioned earlier. Not text equivalents (a), image maps (f)
not tables (g, h), not frames (i) nor skip links (o).

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

From: Andrew Kirkpatrick
Date: Mon, Oct 23 2006 11:35 PM
Subject: Re: Group A distinguishing

> I reluctantly continue here with the same subject only to say
> that I totally disagree with Andrew (with whom I usually
> totally agree) - in this

Excellent. I love to argue with Jim!

> I think only l (scripting) might fall under the interface
> elements requirement I mentioned earlier. Not text
> equivalents (a), image maps (f) not tables (g, h), not frames
> (i) nor skip links (o).

Do you agree that a table is a user interface element? When we talk
about adequate information about user interface elements in 1194.21, do
you include table-like UI controls, or are they not present in
"Software", just in web sites?

Tables and other UI elements are part of software, just as they are part
of web sites. It seems that the reason that there is only one standard
in 21 for this and multiple individual standards in 22 is that there is
the general conception that there are only a few UI elements in HTML and
an unlimited array of possibilities for software. Why is one standard
sufficient for 21 but not for 22?

I'm not suggesting, by the way, that we should stop suggesting that
developers provide titles for HTML frames or table headings in HTML
table elements, but that these are more similar than people currently
acknowledge and that they are either overrepresented in HTML or
underrepresented in software.

AWK

From: Sailesh Panchang
Date: Tue, Oct 24 2006 7:55 AM
Subject: Re: Group A distinguishing

Andrew wrote:
>Do you agree that a table is a user interface element? When we talk
>about adequate information about user interface elements in 1194.21, do
>you include table-like UI controls, or are they not present in
>"Software", just in web sites?
Not all data tables are 'user interface elements'... only those which
involve user interaction might be UI tables. The content in the table will
change based on user interaction. And these are available in Web apps and
in software apps. Both need header-data cell relationships to be
established like in plain non-UI data tables.
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: Hoffman, Allen
Date: Tue, Oct 24 2006 8:20 AM
Subject: Re: Group A distinguishing

Andrew wrote:
>Do you agree that a table is a user interface element? When we talk
>about adequate information about user interface elements in 1194.21, do

>you include table-like UI controls, or are they not present in
>"Software", just in web sites?

Sailesh Panchang wrote:
"Not all data tables are 'user interface elements'... only those which
involve user interaction might be UI tables. The content in the table
will change based on user interaction. And these are available in Web
apps and in software apps. Both need header-data cell relationships to
be
established like in plain non-UI data tables."

I agree with Sailesh. consider the grid control in vb.net and others
like it as an example.

Allen hoffman
Department Of homeland Security

From: Sailesh Panchang
Date: Tue, Oct 24 2006 8:40 AM
Subject: Re: Group A distinguishing

Jim wrote:
>for example both software and web could have standards like the following
>modified from WCAG 2.0 and encompassing 1194.21(d):
> For all user interface components, the name, role and state can be
>programmatically determined, values that can be set by the user can be
>programmatically set, and notification of changes to these items is
>available to user agents, including assistive technologies. (Several words
>and phrases need definitions here, but those are available.)
>It is specific, testable, and, as it turns out, is applicable to both
>software and web. The fact that it is applicable to both is good news, but,
>I think, a conclusion to be drawn later in our process.
While a construct like the above might stand the test of time as it is not
technology-specific, I believe an elaborate techniques and guidance document
will be needed so that those charged with implementing the standard fully
comprehend its impact.
Without such a guidance doc, it will be challenging for developers and
testers to ensure all elements to which the above standard applies complies
with the requirement. At present it is straight forward.:
- identify if a page has repetitive group of links- if yes, para (o)
applies;
- does a page have a data table? Then para (g) or (h) applies, etc.

The complementary document should be drawn up now along with the standard so
that everyone understands the import of the requirement before it it becomes
'law'.

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: Barrett, Don
Date: Tue, Oct 24 2006 9:35 AM
Subject: Re: Group A distinguishing

"
" Are people comfortable with the idea of taking a standard
" like 22g (Row and Column headers...) out of 22 since it is
" covered by a standard like what Jim proposes above? For the
" record, I am.

.22[g] is one of the easiest standards to explain and test for and thus
yields a high level of accessibility as it is specific without being
restrictive. Developers need specifics, not global generalities which
they will never grasp. Half of them don't even understand the specific
standards, let alone the global catch-alls this would lead to.

From: Barrett, Don
Date: Tue, Oct 24 2006 9:45 AM
Subject: Re: Group A distinguishing

There is a difference between principles and standards. Let's not make
the standards so general that 5they look like principles.

From: Jim Thatcher
Date: Tue, Oct 24 2006 9:55 AM
Subject: Re: Group A distinguishing

Both Sailesh and Andrew interpret the guideline I mentioned far broader than
I do. I mentioned this (modified) WCAG 2.0 criterion,

For all user interface components, the name, role and state can be
programmatically determined, values that can be set by the user can be
programmatically set, and notification of changes to these items is
available to user agents, including assistive technologies.

I mentioned it only as a replacement for a less specific and less testable
1194.21(d):

Sufficient information about a user interface element including the
identity, operation and state of the element shall be available to assistive
technology. When an image represents a program element, the information
conveyed by the image must also be available in text.

I don't think that the "name role and state" requirement has anything to do
with tables, skip links, frames etc. as Sailesh and Andrew seem to have
concluded. It is talking about user interface elements like check boxes or
tree views which are interactive objects on the web or in software programs.

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

From: Barrett, Don
Date: Tue, Oct 24 2006 10:00 AM
Subject: Re: Group A distinguishing

" I don't think that the "name role and state" requirement has
" anything to do with tables, skip links, frames etc. as
" Sailesh and Andrew seem to have concluded. It is talking
" about user interface elements like check boxes or tree views
" which are interactive objects on the web or in software programs.

Jim I agree.

From: Hoffman, Allen
Date: Tue, Oct 24 2006 11:50 AM
Subject: Re: Group A distinguishing

Jim wrote:
" I don't think that the "name role and state" requirement has "
anything to do with tables, skip links, frames etc. as " Sailesh and
Andrew seem to have concluded. It is talking " about user interface
elements like check boxes or tree views " which are interactive objects
on the web or in software programs."

I agree that is what this was written to address.

But are these attributes also useful for tabular elements, whether for
software or web. Identify of a table cell is drawn from the column or
row header information, the role may be editable, read-only, navigable,
or such, the state may be "null", or other contents, and there probably
is some coordinate reference information for a tabular cell, as well as
a table itself. I am not familiar with things like the grid controls in
c#, to know if these are attributes associated with these kinds of
objects, but how are table cells and tables displayed via software
substantially different than those produced by interpreted markup?

Just an aside, one thing to make the standards when final less confusing
is to *not* put two testable conditions into one standard. It makes
making straightforward test plans with condition, expected outcome, and
result a lot more complicated, when, for example, a standard actually
has two tests, and several outcomes.

Allen Hoffman
Department of Homeland Security
Office on Accessible Systems & Technology

From: Hoffman, Allen
Date: Tue, Oct 24 2006 12:25 PM
Subject: Re: Group A distinguishing

Suggested language:

When tabular or coordinate-based software or web interface elements are
used, information for identity, operation, state, focus, and content
must be programmatically exposed to assistive technology to allow the
end-user to access the information and relationships presented.

This sums up where my thoughts are going with the concept of combining
web and software provisions, at least for tables.

I suppose one might expand it to far, and cover other interface
elements, but that might be a bit hard to understand.

When software or web user interface elements are used to convey
information, prompt for and action, or perform interaction between the
user and the EIT, , including tabular or coordinate-based elements,
information for identity, operation, state, focus, and content must be
programmatically exposed to assistive technology to allow the end-user
to access the information and relationships presented.

(mouthful)!

This reads to me as a set, a condition (even if it is a long string of
or conditions), and an outcome, or requirement.

I'm certainly not attached to any of this writing, just providing some
example for us to chew on.

Allen Hoffman
Department of Homeland Security

From: Andrew Kirkpatrick
Date: Tue, Oct 24 2006 12:30 PM
Subject: Re: Group A distinguishing

> I don't think that the "name role and state" requirement has
> anything to do with tables, skip links, frames etc. as
> Sailesh and Andrew seem to have concluded. It is talking
> about user interface elements like check boxes or tree views
> which are interactive objects on the web or in software programs.

Just because some of these are often taken care of in HTML doesn't mean
that they don't need to be dealt with in many other cases. For example,
if someone designs a tabular layout with PRE elements they are not
exposing the accurate role as a result of not using the correct element.
Similarly, if you don't use a TH element for a table heading, you aren't
representing the role correctly. Name applies to images, whether
interactive or not. We even require "description" for tables via the
summary attribute...

There are best practices and established methods for dealing with common
HTML accessibility issues, and I don't want to remove these entirely,
but there are too many cracks that new or unusual development patterns
can fall through, and an uber-standard that can include these other
issues and that can also provide requirements that encompass these.

AWK

From: Barrett, Don
Date: Tue, Oct 24 2006 2:00 PM
Subject: Re: Group A distinguishing

You're right Andrew, but that's the problem. What are the best
practices with software? Are they as easy to define as th tags, or td
with scope or header and id tags? HTML tables are more content than
application, and mark-up is vastly different than under-the-hood code
which can't be discerned.

We see grid controls in statistical analysis packages all of the time
which will never speak because GW Micro or Freedom or Dolphin haven't
scripted for them. In fact, Excel wouldn't speak if it hadn't been
scripted for by market forces. The question we get most from developers
is "How do you do it?" The more specific the standard, the easier it is
for them. to understand it. So how do we come up with generalizable
standards without losing the kind of guidance provided by standards like
22 g and h.

From: Peter Korn
Date: Tue, Oct 24 2006 6:40 PM
Subject: Re: Group A distinguishing

Hi Don,

> We see grid controls in statistical analysis packages all of the time
> which will never speak because GW Micro or Freedom or Dolphin haven't
> scripted for them. In fact, Excel wouldn't speak if it hadn't been
> scripted for by market forces. The question we get most from developers
> is "How do you do it?" The more specific the standard, the easier it is
> for them. to understand it. So how do we come up with generalizable
> standards without losing the kind of guidance provided by standards like
> 22 g and h.

The new generation of accessibility frameworks are addressing this
problem. To take the two I'm most familiar with, the Java & UNIX
accessibility frameworks explicitly describe grid controls - we call
them tables and the AccessibleTable interface provides a rich amount of
information about table/grid controls to AT products. Our UNIX AT
products make extensive use of this, and are providing access to all
manner of grid/table controls - including those in GNOME GTK+ apps, in
Java apps, and the StarOffice/OpenOffice.org spreadsheet.

On the Windows side, several Windows AT products support our Windows DLL
that exposes the Java accessibility framework and AccessibleTable.
Using this single interface, ZoomText and Dolphin Supernova (to name two
products) support virtually all uses of the Java Swing JTable, the
Oracle Java table controls in some of their applications, and also the
StarOffice/OpenOffice.org spreadsheet. These products will speak the
row/column header as well as the cell contents, as well as tracking cell
focus with their magnifier components.

All of this doesn't mean there isn't still a role for scripting (such as
JAWS specialized support of spreadsheets); but a fairly good level of
access is possible for all manner of rich, custom user interface
elements by AT, without the need to special-case anything. The three
examples I cited above are three completely different bodies of code,
implementing significantly different table/grid controls (in two
different programming languages, and running on two different
"platforms", developed by three different engineering teams in two
different companies). Yet the use the same basic model of an
accessibility programming interface to describe accessibility table
information to provide the access.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.