Thread Subject: Re: Subcommittee meeting cancelled
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.
Latest draft of definitions are available on the wiki at:
Term that came up today from A/V and Telecom are included.
I went through the EWG draft, noting my questions/comments. Thought I'd
In all but a very few cases, these comments arise because of the
reordering (the fact that text that we already discussed in the
subcommittee reports has moved from a specific section to being text
that applies more broadly).
General comment 1: Many thanks to the EWG for pulling this together! It
was very helpful!
General comment 2: it would be nice to see this not as "1A", "2dB", etc.
but rather fully integrated into the 508 document. So either start
afresh with numbering (so instead of 1194.xx, we create a new section
which supersedes the old one for clarity - e.g. 1294.xx) or use the
existing base numbering of 1194.xx, and integrate that fully into the
document (starting with existing text, Subpart A, etc.). This would help
to fully think through this document in context.
- 2aA was written to apply to telecom hardware, desktop, and portable
hardware. Should it apply to all hardware (e.g. servers?)
- 2aB was written to apply to closed hardware (the other provisions,
namely that it be freestanding, etc. were preserved). Should this be
- 2aC was written for desktop devices. Do we mean to disallow proprietary
expansion slots (e.g. blade servers) in 508? There is no accessibility
purpose served with this. Likewise, do we really need to have this
requirement for card slots in a desktop computer? Again, what a11y
purpose is served by this anymore? Also, is this needed for a cell
phone? (no proprietary memory slots allowed?) [I hope not!]
- 2bA: should this apply to inserting/removing components in a server (or
is that a "maintenance task", and therefore subject to the back office
- 2dB: should we restrict hearing aid interference to only telecom/audio
devices? Perhaps this belongs in the FCC domain, but I'd think we
don't want to cause ringing/interferece with hearing aids in any E&IT,
whatever its function, so long as the way it is naturally operated puts
it close enough to a hearing aid to cause such interference
- 2dD poses an interesting challenge for telecommunications software
running on a general purpose device/computer. If the underlying
computer audio subsystem doesn't provide 18dB gain (which it doesn't
have to, as it isn't a telecom device), then the telecom software will
be unable to do so. I think we need to deal with this case.
- 3aA: second half of this doesn't seem like it belongs in the "All
products" section, as it speaks to operating systems. Also, we should
move away from references to "operating systems", and to "platforms"
instead in many/most cases.
- 3aA: change the text "accessibility programming interface" to
- 3aB: should probably be generalized further; why limit this to just
"Voice mail, messaging, auto-attendant, and interactive voice response
telecommunications systems"? If so limited, shouldn't this be in
a re-titled section 5?
- 3aC: given the use of IP (and for timeliness, UDP) for both voice
and real-time text, I think we should further qualify the 1% error
rate. Unusual heavy disruption of the underlying network can cause
much higher error rates. Something about "under usual conditions"
or something would help here.
- 3cB: perhaps remove the word "bitmap"?
- 4aA: pulling this from the web and applying it to all video content
is a problem; the provisions to pull and apply to all video content
are the more restrictive ones from the Audio Video SC. This text
only makes sense when limited to the web domain. Should just pull
this completely, as 4aB, 4aC, etc. come fro Audio Video and are
fine. Instead put this into the web content section; or qualify
it here to only apply to web content.
- 4aB3: typo in citation at end
- 5A first bullet is not very international (specification of "RJ11
jack"). Perhaps consider other language for this? Also is it (all
analog) and (TDM-digital wired) phones, or (all analog and TDM-digital)
wired phones? Does this apply to analog cell phones (an anachronism
now, I know...)
- 5A second bullet: first words are redundant with the category that
the text is under
- 5C first bullet: how does a TTY work with an IVR system? Do we know
how to do that?
- 5C fourth bullet: are we assuming a 12-key phone touchpad for our
physical control device? This language seems to make assumptions
that aren't future-proof
- 5D calls out software for visual displays; system could be a closed
system with little/no "software" (e.g. all firmware). Perhaps this
language should be more general
- 5E: need a definition of "system" ("...products on that system...").
Also, same concern here as with the 1% language in 3aC. Should have
an additional qualifier that recognizes that IP-based systems can
occasionally go away for a time, or drop a greater number of packets.
- 5E fourth bullet: what is an "audio channel"?
- 6: I don't understand why we have the parenthetical remark, "(for
products, training, or E&IT services)". Seems unnecessary, and perhaps
wrong (could use a different, better, remark)
- 6: suggest you make 6b "for all content" and put it at 6a, then make
6b "specific requirements for web content"; that makes it clear that
the web is simply a specific instance of the general
- 6c: structurally, perhaps have 6aA & 6aB for content, and 6bA and
perhaps 6bB for general authoring and web authoring. Alternately
make authoring its own top-level section. Also, I thought all
Web & Software was working on was general authoring, and not
specifically web authoring.
Sun Microsystems, Inc.
> A link to Editorial Working Group page has been added to the wiki
> For the EWG discussion tomorrow, please read:
> This is all of the current draft provisions, organized in the structure
> of Format #2, thanks to Michele and Whitney!