Thread Subject: Re: Thoughts on Current Web Proposal

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: Barrett, Don
Date: Mon, Mar 26 2007 7:50 AM

Not an easy task Mike. I personally don't view the confusion of screen
reader users as an accessibility issue; ease of use is usability, not
accessibility, but I can't prove that. I just think that requiring that
information be available is one thing, and we should do it; requiring
that it be easy to navigate and utilize is quite another and outside the
scope of 508. There is a very subtle message here about "dummying down"
a site for those struggling screen reader users that concerns me. Just
go to amazon.com with a screen reader and order something; it's not for
the faint of heart, but I do it because I can and that's what is out
there. I've tried the simplified versions of Amazon and they always
lack some feature I need, so I end up back at the monster site as it is
and I manage. It's just very hard to objectify usability into an
accessibility paradigm, and believe me, I don't think naming frames is a
terrible thing at all, so if it stays, so be it.


Don Barrett
Section 508 Coordinator
U.S. Department of Education
(202)-205-8245
= EMAIL ADDRESS REMOVED =

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Fratkin, Mike
Sent: Monday, March 26, 2007 7:22 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

Don, could you please explain why you think that providing meaningful
frame names is merely helpful and no longer a major issue in terms of
site navigation and comprehension. We are seeing commercial applications
using 10-15 frames, many of them just for background processing, and
others with names that do not make sense at all while navigating with a
screen reader. Users tend to get completely lost when there are so many
frames, if the frame names are not meaningful it just confounds the
understanding.

If anything the requirement needs to clarified to include direction on
limiting the numbers of frames and making navigation more
understandable.

Mike Fratkin

[Don wrote:]
Only problem is that the names we are talking about don't show up on the
screen; they are read by the sc4een reader but not displayed, so unless
a person with a learning disability is using a screen reader, they won't
help. I stand by my original suggestion to remove this standard.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
= EMAIL ADDRESS REMOVED =
Sent: Sunday, March 25, 2007 6:25 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

Hi Don,

In your below message, you write:
> 5. I am wondering if we should delete the frames requirement
1194.22(i).
At least for screen readers, definitive frame naming is helpful, but no
longer a major issue in terms of site navigation and comprehension.

RS: I agree with this aspect for screen readers, however, I would
think, without seeming to be an expert on this, that individuals with
dyslexia would find intuitive frame names as 1helpful navigational aids.

Regards,

Rajiv


-----Original Message-----
.From: "Barrett, Don"< = EMAIL ADDRESS REMOVED = >
.Sent: 3/25/07 12:31:50 PM
.To:
" = EMAIL ADDRESS REMOVED = "< = EMAIL ADDRESS REMOVED = >
.Subject: [teitac-websoftware] Thoughts on Current Web Proposal .
.Some Loose Ends I Have Been Thinking About with Regard to the Current
.Iteration of the Web Standards per Andy's post on the WIKI .
.1. We have deferred 1194.22(b) to the AV group. by deferring this, the
.web standards lose their property of being self-contained. Each set of
.standards was developed by the Board so they could stand alone; so, for
.example, both the software standards and the web standards had a
.requirement for forms accessibility. Since captioning on the web is
.critical, we might consider keeping that standard in the web group. If
.the AV subcommittee can make a recommendation to enhance it, we can
.adopt it, but it still belongs in the web standards in whatever form it
.takes.
.
.2. I have had some concern about the lack of clarity and specificity in
.the term "programmatically determined" when used alone in any given
.standard. It looks like the term is defined as part of the proposed
.22(d) standard. This is very helpful, and I would like to suggest that
.whenever the phrase is used as an object in a standard such as in the
.proposed standard, its definition always follow it. I think this will
.provide the same level of clarification as do the table-specific
.examples in the proposed 22(g). However, when the term is used as an
.adjective as in "2.4.4 The purpose of each link can be determined from
.the link text and its programmatically determined link context," it
.probably doesn't require expansion, since by reference, it will mean
.what it means as fleshed out when used as the object in other
standards.
.
.
.3. in the proposed replacement for 22(e) and 22(f) and 21(a),
.* 2.1.1 "All functionality of the content is operable through a
keyboard .interface without requiring specific timings for individual
keystrokes, .except where the underlying task requires analog,
time-dependent input,"
.the phrase "analog, time-dependent input" has been a sticking point for
.some of us. How do people feel about something like this:
."All functionality of the content is operable through a keyboard
.interface without requiring specific timings for individual keystrokes,
.except where the underlying task requires a level of control
.unattainable through a keyboard interface."
.
.4. In the above-mentioned standard, "2.4.4 The purpose of each link can
.be determined from the link text and its programmatically determined
.link context," I am wondering if we should change the "and" to "or." I
.think it may be tough to mandate that both the link text "and" the link
.context determine the purpose of a given link. Either the link text
."or" its context must define its purpose, but not both. A good example
.of this is the infamous "click here" link. If it can be understood in
.context, it would be allowable though of course undesirable; the
.standard in its present form would actually disallow the use of links
.such as this, something we can't realistically mandate.
.
.5. I am wondering if we should delete the frames requirement
1194.22(i).
.At least for screen readers, definitive frame naming is helpful, but no
.longer a major issue in terms of site navigation and comprehension.
.
.

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