Thread Subject: Review of , and questions & concerns with 3Sept07 TEITAC draft
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.
Return to this mailing list's archives
From: Peter Korn
Date: Wed, Sep 05 2007 4:35 PM
Subject: Review of , and questions & concerns with 3Sept07 TEITAC draft
Hi guys,
Just as we did for the last TEITAC meeting, running a handful of
products through the provisions to see what issues came up, I went
through the entire 3Sept07 draft, to see how this draft of the language
in total was working from our perspective. I found a number of concerns,
which I share below. It is interesting to note that even though I
participate vigorously in the Web & Software subcommittee, I found
things when looking at provisions in the context of the entire document
that I felt should be revised. Also, we heard from gov't agencies and
the States yesterday that they see an explosion of provisions in these
drafts compared with the 2001 edition - where provisions are redundant
or can be combined, I think it would be very helpful. Finally, I also
noticed some typos...
Below is a quick summary of those concerns & questions. Over the coming
days I hope to mark up the 3Sept07 draft comments fields with these
concerns.
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
======================================
Authoring tools definition:
-> change “used” to “designed”:
New text becomes: "Any software DESIGNED to create or modify content for
publication..."
Content definition:
-> capitalize the first letter
Contrast ratio definition:
-> why in the first note does it say ratio ranges from 1 to 21? Why does
it end at 21?
-> also, what about a definition of “luminance”
Decoration definition:
-> Should this perhaps be only visual sensory experience? Or audio too?
Should we note this?
E&IT definition:
-> it seems to me that by this definition, a copier is NOT E&IT, as the
IT is embedded. Is this the intention?
General Flash and Red Flash Thresholds definition:
-> item #2 should replace “greater” with “less”, as in:
...The flashing is LESS than 50 Hz [replaces: below 55 Hz]; and...
Menu definition:
-> this needs to be scoped, perhaps just to telecom or “audio menus”. As
it reads now, things like a collection of radio buttons would be
considered a menu. Also, where is this term used in 508? three things to
consider: instead of “Set of selectable options”, what about
“Presentation of a set of selectable options”, or “Presentation of a set
of user-selectable options”. But in either case, we should note that
this is an audio/aural presentations
Platform Accessibility Services definition:
-> would like to replace “sometimes” with “commonly”, as in:
...Services provided by a platform enabling interoperability with
assistive technologies COMMONLY in the form of accessibility APIs...
Programmatically Determined definition:
-> Shouldn't this be “Programmatically Determinable”?
Real-time Text definition:
-> do we really need the phrase “by a terminal” in this text?
Terminal definition:
-> do we really need the plural “or devices”? Is a terminal a plural
object?
Video Description definition:
-> Is the second paragraph intended to be part of the definition?
1.1-C - Without Color Vision Deficits
-> Text is not testable, and in fact doesn't map well to existing
technical standards:
“Products must provide at least one mode that allows access for people
with color vision deficits” - but what does this mean in reality? We
already say you cannot use color as the sole way of conveying info, so
all modes should have that characteristic. Also, what sort of color
vision deficits? There is a wide range of them...
-> Compare this text with 3-A – Color, which states things much more
clearly.
1.1-E – With Limited Hearing
-> text says: “...at least one mode that allows access with enhanced
audio...” What is “enhanced audio”? It isn't defined in the definitions.
Is it just boosting the volume? Some sort of simple audio filter? As
complex an audio filter as we have in modern digital hearing aids? What?
1.1-G – With Limited Reach, Strength, or Manipulation
-> text says: “...and that does not require simultaneous actions...”
This is directly covered in 2.1-C(2). Do we really need this to be
duplicated in the FPC?
1.1-I – With Cognitive, Language or Learning Limitations
-> Second word seems missing. Change “Product provide at least one
mode...” to “Products MUST provide at least one mode...”
-> Note further, in the discussion/rationale section, it claims Dr.
Lewis put forth 3 features. He put forth 5. Three are addressed by our
new 3-V provisoin (AT interoperability), one we already had, and the
fifth is in advisory 3-X(1) Suppression of unneeded functions.
1.2-A – Closed Product Functionality
-> This reads like an FPC. It is not clearly testable. I think it
belongs in the FPC section
1.2-D – Pass Throughout
-> This continues to have the same problem it had months ago (when I
noted it back then). Virtually every computing device “transmits or
conducts information or communication”, so this would apply to things
like disk drive firmware and a huge host of other things that have no
user input impact. It is nonsensical.
1.2-E – Audio Information
-> Sounds like another FPC. I note it came from closed, so why “directly
or via AT” in it as well? This is not testable and doesn't belong in the
technical provisions
1.2-F – Visual Information
-> Same comment as above. Another FPC, came from closed, has “directly
or via AT”, and is not testable. It doesn't belong in the technical
provisions.
1.2-H – Text size
-> Incorporate the second "note" of 3-U as a note here as well, as this
provision now covers a lot more than just the closed products (the SC
that it came from)
2.1-C – Mechanical Controls
-> I'm curious, where did the 2 second number come from? Is this
essentially SlowKeys in disguise?
2.1-D – Touch Operated Controls
-> sounds like a FPC, with “directly or through AT” in it. I'm concerned
about testability of this provision... [Note: in the meeting earlier
today we agreed to remove the "directly or with AT" text]
3-B – Contrast
-> We should see if we can make this text more general, rather than
limiting it to “electronic documents” and then having separate
provisions (3-P & 3-Q) that talk about contrast for user interfaces.
3-G – Flashing
-> This provision notes that it is a subset of 1.2-B Flashing. If so,
why is it needed here? Seems redundant and removable.
3-I – Size, shape, location
-> Should clarify that “Instructions” applies to instructions that are
part of the user interface presentation, not printed documentation
3-J – Audio turnoff
-> We should clarify the situation for web pages: better if the web
browser had this responsibility, so web pages that played sound didn't
have to explicitly include a 'turn sound off' button when the browser
can do this function more universally (less burned on programmers to do
this once in the browser). Perhaps this could be done in an advisory
note...?
3-K – Reading Sequence
-> See the text in 8.1-C Reading Order; that uses the phrase “logical,
linear reading order”, vs. “a correct reading sequence”. I don't know
what “correct” is. How can it be tested? Though I understand this text
comes from WCAG, I find it difficult (and would prefer to use the 8.1-C
text).
3-L – Repeated Blocks
-> Better to use structure for this [I believe yesterday we agreed to do
that...]
3-N – Information and Relationships
-> This provision pretty clearly assumes it is talking about a document,
but it doesn't mention it explicitly (and there, an XML/HTML document).
In (2), (3), and (4) it directs the explicit use of “markup” to do
things (all of which are covered in 3-V). This provision should either
be removed as redundant, or scoped to explicitly apply to (web) documents.
3-O – User Interface Components
-> Like 3-N, this is really about (web) documents; everything in it is
covered by 3-V. I think we should either remove it as redundant, or
scope to it web documents.
3-P – User Preferences
-> Best placed right after 3-A Color, as this is really all about
color/contrast preferences
3-Q – Color Adjustment
-> Best placed right after 3-B Contrast, as this is really about color
changes that can result in specific minimum contrast levels
-> alternately place 3-P and 3-Q together right after 3-B
3-T – Keyboard Operation
-> A long time ago this provision (or something like it) was scoped to
systems that had a keyboard. Now it essentially says that something like
an iPhone has to have a keyboard (or at least, have a UI operable by a
keyboard). That doesn't make sense to me.
3-V – AT Interoperability
-> Please note the final text “Note: This provision applies to forms in
the software”. With that comment, 3-V subsumes the need for 3-O
4-A – Caption Playback
-> In the “Material for inclusion in the additional notes document:”
section, the 7th bullet says “Support options for altering the
appearance of caption character edges”. What does this mean? What are
some of the potential options? As an engineer, how can I know if I've
done this?
-> In the same section, 8th bullet says “Support the authoring and
selection of the six caption services...”. What are these? I've never
heard of this before.
5-B – Real-Time Text Reliability and Interoperability
-> 5-C says you must have/support RTT. Saying it also in this provision
is redundant (first sentence)
5-C – Voice Terminal Hardware and Software
-> This structure is poor. Essentially it says: “Do A. If you haven't
done A, do B.” Better to say: “You must either to A or do B (or do both)”.
5-D – IVR, Auto-Attendant and Messaging
-> Text of item 1 says “All functions that are accessible to voice users
must also be direct accessible to users of real-time text.” How do we do
that for a voice-prompted menu? Has anyone prototyped this? We shouldn't
put anything into a testable provision that we don't know how to do.
5-E – Caller and Status Information
-> This says that products with visual interfaces that display status
info must make the info available for TTYs among others. How do I make
Skype's connection information available to a TTY? This provision is
making assumptions about the device that don't match the text of the
provision.
6-A – Synchronized Alternatives
-> this is a very broad provision that applies to practically all media;
6-B and 6-C limits the scope in which alternatives must be synchronized.
I think this provision doesn't belong and should be removed; certainly
it contradicts 6-B(1) and 6-C(1).
6-B – Captioning and Transcripts
-> (2) and (3) note that captions must be provided for things with
concurrent audio. But really, don't we mean for concurrent spoken audio?
Perhaps a nit, as you only caption speech, but...
6-C – Video Description
-> I think (3) is too broad. Think of the situation of a recording of a
video slide presentation. If the (accessible) slides are provided
separately, and the speaker refers to each slide name/number when moving
to a new slide, haven't we made this presentation accessible? Do we need
to actually provide verbal descriptions of the slide text?
From: awoolley@cusa.canon.com
Date: Wed, Sep 05 2007 9:30 PM
Subject: Re: Review of , and questions & concerns with 3Sept07 TEITAC draft
<FONT face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size=2><DIV>Hi Peter, </DIV><DIV> </DIV><DIV>Thank you for all the valuable comments.</DIV><DIV> </DIV><DIV>If I may respond to one...</DIV><BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"><DIV><FONT face="Default Monospace,Courier New,Courier,monospace">PK: E&IT definition:<BR>-> it seems to me that by this definition, a copier is NOT E&IT, as the <BR>IT is embedded. Is this the intention?</FONT><BR></DIV></BLOCKQUOTE><P>Copiers are listed in the E&IT definition "includes, but is not limited to" list of covered products (Sept 3rd Draft). There was also a list of products included in the final sentence to clarify what is meant by the exclusion of products with embedded IT where IT is not the principal use of the product (such as HVAC systems and medical equipment). Since it looks like these examples have been removed, I would agree that it is a bit ambiguous as written. <BR><BR>Aubrey<BR><BR>Aubrey Woolley<BR>Government Marketing Division<BR>Canon USA, Inc.<BR><BR></P></FONT>
From: Gregg Vanderheiden
Date: Wed, Sep 05 2007 9:45 PM
Subject: Re: Review of , and questions & concerns with 3Sept07 TEITAC draft
Answers provided to some of the questions - to assist discussion.
Good review. Even for the items that have answers - If Peter had these
questions - we should capture rationale for others later.
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> Contrast ratio definition:
> -> why in the first note does it say ratio ranges from 1 to
> 21? Why does
> it end at 21?
Look at the formula. That is the highest value you can get with pure white
on pure black.
>
> Decoration definition:
> -> Should this perhaps be only visual sensory experience? Or
> audio too?
> Should we note this?
The definition could apply to either - but we only use it for visual in the
standard.
>
> E&IT definition:
> -> it seems to me that by this definition, a copier is NOT
> E&IT, as the
> IT is embedded. Is this the intention?
A copier is IT. So is printer.
>
> Menu definition:
> -> this needs to be scoped, perhaps just to telecom or "audio
> menus". As
> it reads now, things like a collection of radio buttons would be
> considered a menu. Also, where is this term used in 508?
> three things to
> consider: instead of "Set of selectable options", what about
> "Presentation of a set of selectable options", or
> "Presentation of a set
> of user-selectable options". But in either case, we should note that
> this is an audio/aural presentations
Hmmmm
Menu is used in a number of places..... We need to be careful of each
ones.
>
> Real-time Text definition:
> -> do we really need the phrase "by a terminal" in this text?
>
I believe that phrase was included to prevent the 1 second from being
applied to things that retransmit the text enroute.
> 1.1-C - Without Color Vision Deficits
> -> Text is not testable, and in fact doesn't map well to existing
> technical standards:
> "Products must provide at least one mode that allows access
> for people
> with color vision deficits" - but what does this mean in reality? We
> already say you cannot use color as the sole way of conveying
> info, so
> all modes should have that characteristic. Also, what sort of color
> vision deficits? There is a wide range of them...
> -> Compare this text with 3-A - Color, which states things much more
> clearly.
There is more to color blindness than color coding. But color-coding and
contrast provisions pretty much cover it. Need a FPC for functional
equivalence though yes?
> 1.1-G - With Limited Reach, Strength, or Manipulation
> -> text says: "...and that does not require simultaneous actions..."
> This is directly covered in 2.1-C(2). Do we really need this to be
> duplicated in the FPC?
This is from old FPC. Not covered by reach strength or manip.
Need for Equiv Facil?
> 1.2-A - Closed Product Functionality
> -> This reads like an FPC. It is not clearly testable. I think it
> belongs in the FPC section
This is not FPC. It specifies which technical apply. Should be as testable
as the Technical. No?
>
> 1.2-D - Pass Throughout
> -> This continues to have the same problem it had months ago (when I
> noted it back then). Virtually every computing device "transmits or
> conducts information or communication", so this would apply to things
> like disk drive firmware and a huge host of other things that have no
> user input impact. It is nonsensical.
It says that these things should not strip disability access information in
the process. For most things it would be no issue. In places where it
does apply it would be important.
I think the last "usable" is supposed to be Accessible.
> 1.2-E - Audio Information
> -> Sounds like another FPC. I note it came from closed, so
> why "directly
> or via AT" in it as well? This is not testable and doesn't
> belong in the
> technical provisions
This is technical. The "directly or via AT" was added to allow AT to be
used to meet the provision. This is critical for ensuring access by people
who are blind and have other disabilities. Not clear why this would not be
testable. It would seem to be much more testable than many/most technical
provisions
>
> 1.2-F - Visual Information
> -> Same comment as above. Another FPC, came from closed, has
> "directly
> or via AT", and is not testable. It doesn't belong in the technical
> provisions.
Ditto.
>
> 1.2-H - Text size
> -> Incorporate the second "note" of 3-U as a note here as
> well, as this
> provision now covers a lot more than just the closed products (the SC
> that it came from)
Good comment.
>
> 2.1-C - Mechanical Controls
> -> I'm curious, where did the 2 second number come from? Is this
> essentially SlowKeys in disguise?
This doesn't have anything to do with slowkeys which is delay before a key
is accepted. This is delay before auto-repeat is activated. This is
harmonized with multiple standards. And was derived from the reaction time
for removal of hand from key for people with CP etc.
>
> 2.1-D - Touch Operated Controls
> -> sounds like a FPC, with "directly or through AT" in it.
> I'm concerned
> about testability of this provision... [Note: in the meeting earlier
> today we agreed to remove the "directly or with AT" text]
>
> 3-B - Contrast
> -> We should see if we can make this text more general, rather than
> limiting it to "electronic documents" and then having separate
> provisions (3-P & 3-Q) that talk about contrast for user interfaces.
>
They are similar but need to be different since one actually generates
luminance and one is only relative luminance. But could (should?) be
brought together. There are benefits to having the contrasts together and
to having hardware with hardware and content/software with software. tough
call.
> 3-J - Audio turnoff
> -> We should clarify the situation for web pages: better if the web
> browser had this responsibility, so web pages that played
> sound didn't
> have to explicitly include a 'turn sound off' button when the browser
> can do this function more universally (less burned on
> programmers to do
> this once in the browser). Perhaps this could be done in an advisory
> note...?
>
Good idea to add note. Mechanism is used in WCAG to allow browser to be
used but requiring content to provide mechanism if they implement in a way
that browser has no control
> 3-T - Keyboard Operation
> -> A long time ago this provision (or something like it) was
> scoped to
> systems that had a keyboard. Now it essentially says that
> something like
> an iPhone has to have a keyboard (or at least, have a UI
> operable by a
> keyboard). That doesn't make sense to me.
>
Agree. Good catch. This should have lead phrase that says "Software that
is run on products that may include keyboards or keyboard interfaces .....
Note however, that a touchscreen phone may very well also allow the
connection of a keyboard for easier messaging or browsing at home or hotel -
so it may still apply to this type of device. But if not - then the
provision should not require keyboard support.
>
> 5-B - Real-Time Text Reliability and Interoperability
> -> 5-C says you must have/support RTT. Saying it also in this
> provision
> is redundant (first sentence)
>
Not redundant because
5-B applies to all voice communication products
5-C only applies to terminals.
> 5-C - Voice Terminal Hardware and Software
> -> This structure is poor. Essentially it says: "Do A. If you haven't
> done A, do B." Better to say: "You must either to A or do B
> (or do both)".
Read more carefully. It isn't a do A. if not do B. it is a case like
statement
If a is true do this
If b is true do this
If c is true do this
If d is true do this
>
> 5-D - IVR, Auto-Attendant and Messaging
> -> Text of item 1 says "All functions that are accessible to
> voice users
> must also be direct accessible to users of real-time text."
> How do we do
> that for a voice-prompted menu? Has anyone prototyped this?
> We shouldn't
> put anything into a testable provision that we don't know how to do.
>
This is doable in TTY and real-time text.
> 5-E - Caller and Status Information
> -> This says that products with visual interfaces that display status
> info must make the info available for TTYs among others. How
> do I make
> Skype's connection information available to a TTY? This provision is
> making assumptions about the device that don't match the text of the
> provision.
Skype is IP. You wouldn't use a TTY with Skype.
>
> 6-A - Synchronized Alternatives
> -> this is a very broad provision that applies to practically
> all media;
> 6-B and 6-C limits the scope in which alternatives must be
> synchronized.
> I think this provision doesn't belong and should be removed;
> certainly
> it contradicts 6-B(1) and 6-C(1).
Don't see the contradiction.
6-B(1) and 6-C(1) are not multimedia (or synchronized media now)
>
> 6-B - Captioning and Transcripts
> -> (2) and (3) note that captions must be provided for things with
> concurrent audio. But really, don't we mean for concurrent
> spoken audio?
> Perhaps a nit, as you only caption speech, but...
Both are limited by the header which limits them to " speech or other audio
information necessary for the comprehension of the content,"
From: Jared Smith
Date: Wed, Sep 05 2007 10:55 PM
Subject: Re: Review of , and questions & concerns with 3Sept07 TEITAC draft
Gregg just beat me to the punch on a few of these, but here's my
comments/additions.
On 9/5/07, Peter Korn wrote:
> Authoring tools definition:
> -> change "used" to "designed":
> New text becomes: "Any software DESIGNED to create or modify content for
> publication..."
I think 'intended' would be better. We don't want this to be
interpreted to apply to the design of the authoring tool itself.
> Contrast ratio definition:
> -> why in the first note does it say ratio ranges from 1 to 21? Why does
> it end at 21?
The maximum value allowed by the formula defined under "Relative
Luminance" is 21. Or at least, that's how I understand it. It's too
late to do complex math, so I'm going to trust that this is correct.
> -> also, what about a definition of "luminance"
Luminance is defined under "Relative Luminance". We need to make sure
we are using "luminance" and "relative luminance" correctly and
consistently throughout.
> Decoration definition:
> -> Should this perhaps be only visual sensory experience? Or audio too?
> Should we note this?
The only places it is mentioned is in the visual provisions, but this
should be clarified in the definition as well.
> General Flash and Red Flash Thresholds definition:
> -> item #2 should replace "greater" with "less"
This was an editorial mistake and has been fixed in the online version.
This should also just be renamed "Flash Thresholds" for simplicity.
The reference to "images" needs to be removed as non-images can also
flash. We also need to either remove the Red threshold or better
define "saturated red." I'm beginning to feel like a broken record on
this one. :-(
Also note the previous request from Gregg and I to add "... at a
typical viewing distance" to the end of 3. Without it, the threshold
is unmeasurable.
> Programmatically Determined definition:
> -> Shouldn't this be "Programmatically Determinable"?
It depends on the context. It can be either "*can be* programmatically
determined" OR "*is* programmatically determinable". We should make
all of these consistent if possible and I think "can be
programmatically determined" is more clear.
> 3-G – Flashing
> -> This provision notes that it is a subset of 1.2-B Flashing. If so,
> why is it needed here? Seems redundant and removable.
Yes, I've argued a few times that they should be combined. 3-G needs
the 3 second allowance and needs the status indicators exemption. We
need feedback from hardware regarding the implications of combining
them.
> 3-J – Audio turnoff
> -> We should clarify the situation for web pages: better if the web
> browser had this responsibility, so web pages that played sound didn't
> have to explicitly include a 'turn sound off' button when the browser
> can do this function more universally
But you can't scope 'browsers'. If all of them did this, then this
could be allowable. Until then, I think it needs to be built in. But
an advisory note on this would be good.
I have a similar question about the Pausing provision. Hitting ESC
pauses animation in some browsers but not others, so is this
sufficient or must I build a pause control for animations (something
that's a bit difficult with even .gif images in HTML)?
> 3-L – Repeated Blocks
> -> Better to use structure for this [I believe yesterday we agreed to do
> that...]
I *thought* we agreed to move this to an advisory note and need to
make sure it gets moved, not deleted (as the updated version
indicates).
> 3-N – Information and Relationships
> -> This provision pretty clearly assumes it is talking about a document,
> but it doesn't mention it explicitly (and there, an XML/HTML document).
> In (2), (3), and (4) it directs the explicit use of "markup" to do
> things (all of which are covered in 3-V). This provision should either
> be removed as redundant, or scoped to explicitly apply to (web) documents.
The word "markup" can be removed to make this more general. 3-N is
quite distinct from 3-V. 3-V are thing the user agent and software
must communicate (presumably) through an API. 3-N are things the
content/software author must do to provide 3-V the sufficient
information to communicate. Combining them muddies the water as to
where accessibility happens and it happens at the authoring level
(3-N) and the AT-IT intersection (3-V).
> 3-O – User Interface Components
> -> Like 3-N, this is really about (web) documents; everything in it is
> covered by 3-V. I think we should either remove it as redundant, or
> scope to it web documents.
Similar to my comments above, though this one is less distinct in my mind.
I also recommend that we add additional advisory notes to 3-X, where
appropriate, to further address some of the WCAG 2.0 provisions that
have been excluded. Primarily:
- Parsing (Level A)
- Descriptive Page Titles (Level A)
- Focus Order (Level A)
- Error identification (Level A)
- Error suggestion (Level AA)
- Descriptive headings and labels (Level AA)
These are the Level AA or below items not currently in the draft that
should at least receive honorable mention in advisory notes. If this
is agreeable, I can work on pulling out the relevant text and
structuring it - we'll probably need a "Web only" section in 3-X.
This thread is likely going to get real messy if there are a lot of
responses. Perhaps tracking all of this on a new wiki page would make
more sense.
Jared Smith
National Center or Disability and Access to Education
From: Jim Allan
Date: Thu, Sep 06 2007 8:15 AM
Subject: Re: Review of , and questions & concerns with 3Sept07 TEITAC draft
Nice work Peter.
A comment on one item...
Peter Corn wrote:
> 3-J – Audio turnoff
> -> We should clarify the situation for web pages: better if the web
> browser had this responsibility, so web pages that played sound didn't
> have to explicitly include a 'turn sound off' button when the browser
> can do this function more universally (less burned on programmers to do
> this once in the browser). Perhaps this could be done in an advisory
> note...?
The browser (user agent) can only turn off sound that it knows about, such
as the <bgsound> element. If the author uses <embed> or <object> to contain
FLASH or media player sounds or some JavaScript to play the sound the
hosting user agent has no "knowledge" or control of what occurs in these
elements.
Jim
From: Diane Golden
Date: Thu, Sep 06 2007 8:20 AM
Subject: Re: Review of , and questions & concerns with 3Sept07 TEITAC draft
http://a257.g.akamaitech.net/7/257/2422/05dec20031700/edocket.access.gpo.gov/cfr_2003/octqtr/pdf/47cfr68.317.pdf
This should link you to the FCC reg. I'm fairly certain the measurement of gain is acoustic, thus it will be dependent on the speaker, headset, handset or whatever is used for output.
Diane
----- Original Message ----
From: Peter Korn < = EMAIL ADDRESS REMOVED = >
To: = EMAIL ADDRESS REMOVED =
Sent: Wednesday, September 5, 2007 5:30:39 PM
Subject: [teitac-committee] Review of , and questions & concerns with 3Sept07 TEITAC draft
Hi guys,
Just as we did for the last TEITAC meeting, running a handful of
products through the provisions to see what issues came up, I went
through the entire 3Sept07 draft, to see how this draft of the language
in total was working from our perspective. I found a number of concerns,
which I share below. It is interesting to note that even though I
participate vigorously in the Web & Software subcommittee, I found
things when looking at provisions in the context of the entire document
that I felt should be revised. Also, we heard from gov't agencies and
the States yesterday that they see an explosion of provisions in these
drafts compared with the 2001 edition - where provisions are redundant
or can be combined, I think it would be very helpful. Finally, I also
noticed some typos...
Below is a quick summary of those concerns & questions. Over the coming
days I hope to mark up the 3Sept07 draft comments fields with these
concerns.
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
======================================
Authoring tools definition:
-> change “used” to “designed”:
New text becomes: "Any software DESIGNED to create or modify content for
publication..."
Content definition:
-> capitalize the first letter
Contrast ratio definition:
-> why in the first note does it say ratio ranges from 1 to 21? Why does
it end at 21?
-> also, what about a definition of “luminance”
Decoration definition:
-> Should this perhaps be only visual sensory experience? Or audio too?
Should we note this?
E&IT definition:
-> it seems to me that by this definition, a copier is NOT E&IT, as the
IT is embedded. Is this the intention?
General Flash and Red Flash Thresholds definition:
-> item #2 should replace “greater” with “less”, as in:
...The flashing is LESS than 50 Hz [replaces: below 55 Hz]; and...
Menu definition:
-> this needs to be scoped, perhaps just to telecom or “audio menus”. As
it reads now, things like a collection of radio buttons would be
considered a menu. Also, where is this term used in 508? three things to
consider: instead of “Set of selectable options”, what about
“Presentation of a set of selectable options”, or “Presentation of a set
of user-selectable options”. But in either case, we should note that
this is an audio/aural presentations
Platform Accessibility Services definition:
-> would like to replace “sometimes” with “commonly”, as in:
...Services provided by a platform enabling interoperability with
assistive technologies COMMONLY in the form of accessibility APIs...
Programmatically Determined definition:
-> Shouldn't this be “Programmatically Determinable”?
Real-time Text definition:
-> do we really need the phrase “by a terminal” in this text?
Terminal definition:
-> do we really need the plural “or devices”? Is a terminal a plural
object?
Video Description definition:
-> Is the second paragraph intended to be part of the definition?
1.1-C - Without Color Vision Deficits
-> Text is not testable, and in fact doesn't map well to existing
technical standards:
“Products must provide at least one mode that allows access for people
with color vision deficits” - but what does this mean in reality? We
already say you cannot use color as the sole way of conveying info, so
all modes should have that characteristic. Also, what sort of color
vision deficits? There is a wide range of them...
-> Compare this text with 3-A – Color, which states things much more
clearly.
1.1-E – With Limited Hearing
-> text says: “...at least one mode that allows access with enhanced
audio...” What is “enhanced audio”? It isn't defined in the definitions.
Is it just boosting the volume? Some sort of simple audio filter? As
complex an audio filter as we have in modern digital hearing aids? What?
1.1-G – With Limited Reach, Strength, or Manipulation
-> text says: “...and that does not require simultaneous actions...”
This is directly covered in 2.1-C(2). Do we really need this to be
duplicated in the FPC?
1.1-I – With Cognitive, Language or Learning Limitations
-> Second word seems missing. Change “Product provide at least one
mode...” to “Products MUST provide at least one mode...”
-> Note further, in the discussion/rationale section, it claims Dr.
Lewis put forth 3 features. He put forth 5. Three are addressed by our
new 3-V provisoin (AT interoperability), one we already had, and the
fifth is in advisory 3-X(1) Suppression of unneeded functions.
1.2-A – Closed Product Functionality
-> This reads like an FPC. It is not clearly testable. I think it
belongs in the FPC section
1.2-D – Pass Throughout
-> This continues to have the same problem it had months ago (when I
noted it back then). Virtually every computing device “transmits or
conducts information or communication”, so this would apply to things
like disk drive firmware and a huge host of other things that have no
user input impact. It is nonsensical.
1.2-E – Audio Information
-> Sounds like another FPC. I note it came from closed, so why “directly
or via AT” in it as well? This is not testable and doesn't belong in the
technical provisions
1.2-F – Visual Information
-> Same comment as above. Another FPC, came from closed, has “directly
or via AT”, and is not testable. It doesn't belong in the technical
provisions.
1.2-H – Text size
-> Incorporate the second "note" of 3-U as a note here as well, as this
provision now covers a lot more than just the closed products (the SC
that it came from)
2.1-C – Mechanical Controls
-> I'm curious, where did the 2 second number come from? Is this
essentially SlowKeys in disguise?
2.1-D – Touch Operated Controls
-> sounds like a FPC, with “directly or through AT” in it. I'm concerned
about testability of this provision... [Note: in the meeting earlier
today we agreed to remove the "directly or with AT" text]
3-B – Contrast
-> We should see if we can make this text more general, rather than
limiting it to “electronic documents” and then having separate
provisions (3-P & 3-Q) that talk about contrast for user interfaces.
3-G – Flashing
-> This provision notes that it is a subset of 1.2-B Flashing. If so,
why is it needed here? Seems redundant and removable.
3-I – Size, shape, location
-> Should clarify that “Instructions” applies to instructions that are
part of the user interface presentation, not printed documentation
3-J – Audio turnoff
-> We should clarify the situation for web pages: better if the web
browser had this responsibility, so web pages that played sound didn't
have to explicitly include a 'turn sound off' button when the browser
can do this function more universally (less burned on programmers to do
this once in the browser). Perhaps this could be done in an advisory
note...?
3-K – Reading Sequence
-> See the text in 8.1-C Reading Order; that uses the phrase “logical,
linear reading order”, vs. “a correct reading sequence”. I don't know
what “correct” is. How can it be tested? Though I understand this text
comes from WCAG, I find it difficult (and would prefer to use the 8.1-C
text).
3-L – Repeated Blocks
-> Better to use structure for this [I believe yesterday we agreed to do
that...]
3-N – Information and Relationships
-> This provision pretty clearly assumes it is talking about a document,
but it doesn't mention it explicitly (and there, an XML/HTML document).
In (2), (3), and (4) it directs the explicit use of “markup” to do
things (all of which are covered in 3-V). This provision should either
be removed as redundant, or scoped to explicitly apply to (web) documents.
3-O – User Interface Components
-> Like 3-N, this is really about (web) documents; everything in it is
covered by 3-V. I think we should either remove it as redundant, or
scope to it web documents.
3-P – User Preferences
-> Best placed right after 3-A Color, as this is really all about
color/contrast preferences
3-Q – Color Adjustment
-> Best placed right after 3-B Contrast, as this is really about color
changes that can result in specific minimum contrast levels
-> alternately place 3-P and 3-Q together right after 3-B
3-T – Keyboard Operation
-> A long time ago this provision (or something like it) was scoped to
systems that had a keyboard. Now it essentially says that something like
an iPhone has to have a keyboard (or at least, have a UI operable by a
keyboard). That doesn't make sense to me.
3-V – AT Interoperability
-> Please note the final text “Note: This provision applies to forms in
the software”. With that comment, 3-V subsumes the need for 3-O
4-A – Caption Playback
-> In the “Material for inclusion in the additional notes document:”
section, the 7th bullet says “Support options for altering the
appearance of caption character edges”. What does this mean? What are
some of the potential options? As an engineer, how can I know if I've
done this?
-> In the same section, 8th bullet says “Support the authoring and
selection of the six caption services...”. What are these? I've never
heard of this before.
5-B – Real-Time Text Reliability and Interoperability
-> 5-C says you must have/support RTT. Saying it also in this provision
is redundant (first sentence)
5-C – Voice Terminal Hardware and Software
-> This structure is poor. Essentially it says: “Do A. If you haven't
done A, do B.” Better to say: “You must either to A or do B (or do both)”.
5-D – IVR, Auto-Attendant and Messaging
-> Text of item 1 says “All functions that are accessible to voice users
must also be direct accessible to users of real-time text.” How do we do
that for a voice-prompted menu? Has anyone prototyped this? We shouldn't
put anything into a testable provision that we don't know how to do.
5-E – Caller and Status Information
-> This says that products with visual interfaces that display status
info must make the info available for TTYs among others. How do I make
Skype's connection information available to a TTY? This provision is
making assumptions about the device that don't match the text of the
provision.
6-A – Synchronized Alternatives
-> this is a very broad provision that applies to practically all media;
6-B and 6-C limits the scope in which alternatives must be synchronized.
I think this provision doesn't belong and should be removed; certainly
it contradicts 6-B(1) and 6-C(1).
6-B – Captioning and Transcripts
-> (2) and (3) note that captions must be provided for things with
concurrent audio. But really, don't we mean for concurrent spoken audio?
Perhaps a nit, as you only caption speech, but...
6-C – Video Description
-> I think (3) is too broad. Think of the situation of a recording of a
video slide presentation. If the (accessible) slides are provided
separately, and the speaker refers to each slide name/number when moving
to a new slide, haven't we made this presentation accessible? Do we need
to actually provide verbal descriptions of the slide text?
From: Peter Korn
Date: Thu, Sep 06 2007 9:30 AM
Subject: Re: Review of , and questions & concerns with 3Sept07 TEITAC draft
Hi Jim,
I agree. I consider those "web applications", and as applications, they
have a duty to provide the functionality.
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
> Nice work Peter.
>
> A comment on one item...
>
> Peter Corn wrote:
>
>> 3-J – Audio turnoff
>> -> We should clarify the situation for web pages: better if the web
>> browser had this responsibility, so web pages that played sound didn't
>> have to explicitly include a 'turn sound off' button when the browser
>> can do this function more universally (less burned on programmers to do
>> this once in the browser). Perhaps this could be done in an advisory
>> note...?
>>
>
> The browser (user agent) can only turn off sound that it knows about, such
> as the <bgsound> element. If the author uses <embed> or <object> to contain
> FLASH or media player sounds or some JavaScript to play the sound the
> hosting user agent has no "knowledge" or control of what occurs in these
> elements.
>
> Jim
>
>
From: Peter Korn
Date: Thu, Sep 06 2007 10:10 AM
Subject: Re: Review of , and questions & concerns with 3Sept07 TEITAC draft
Hi Diane,
Thanks for this pointer. I think this text points out a problem with
our current draft 2.2-E(3). That text says: "All other
telecommunications products or systems that provide a function allowing
voice communication must provide a gain adjustable from the normal
unamplified level to at least 20 dB above the normal unamplified level
as measured in accordance with the provisions of the FCC regulation
§68.317 for volume control. The volume at the normal unamplified level
setting must also meet the requirement in FCC regulation 68.317."
As the link that Diane posted makes clear, the FCC 68.371 language
directs vendors to measure audio level "through the receiver in the
handset or headset of the telephone". The longer text is: "digital
telephone complies with the Commission’s volume control requirements if
the telephone is equipped with a receive volume control that provides,
through the receiver of the handset or headset of the telephone, 12 dB
of gain minimum and up to 18 dB of gain maximum". Separate from whether
the gain should stay at the 68.371 level of 18 dB, or whether it
increases to 20 dB, is the issue for computer-based VoIP solutions where
the computer is sold separately from the voice chat program is sold
separately from the headset. We can't place a burden on software like
Skype that can only be measured through a headset that they don't
control. And what of the computer - do we penalize the Dell laptop that
Skype is running on if Skype doesn't expose via a software user
interface a volume control that does 20 dB?
So I think we need to change 2.2-E(3) to have language that firstly
doesn't depend upon the 68.317 measurement technique, and secondly
recognizes that software audio telecommunications products like Skype
don't control all of the pieces and so provisions should only require of
them things they can control.
In an interesting way, this is essentially the same problem as we have
with making the FPC language "usable with AT" something we test. As IT
doesn't control AT - as Skype doesn't control the audio hardware in a
DELL laptop or a Jabra headset - we cannot require it to do things it
cannot control.
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
> http://a257.g.akamaitech.net/7/257/2422/05dec20031700/edocket.access.gpo.gov/cfr_2003/octqtr/pdf/47cfr68.317.pdf
>
> This should link you to the FCC reg. I'm fairly certain the
> measurement of gain is acoustic, thus it will be dependent on the
> speaker, headset, handset or whatever is used for output.
>
> Diane
>
> ----- Original Message ----
> From: Peter Korn < = EMAIL ADDRESS REMOVED = >
> To: = EMAIL ADDRESS REMOVED =
> Sent: Wednesday, September 5, 2007 5:30:39 PM
> Subject: [teitac-committee] Review of , and questions & concerns with
> 3Sept07 TEITAC draft
>
> Hi guys,
>
> Just as we did for the last TEITAC meeting, running a handful of
> products through the provisions to see what issues came up, I went
> through the entire 3Sept07 draft, to see how this draft of the language
> in total was working from our perspective. I found a number of concerns,
> which I share below. It is interesting to note that even though I
> participate vigorously in the Web & Software subcommittee, I found
> things when looking at provisions in the context of the entire document
> that I felt should be revised. Also, we heard from gov't agencies and
> the States yesterday that they see an explosion of provisions in these
> drafts compared with the 2001 edition - where provisions are redundant
> or can be combined, I think it would be very helpful. Finally, I also
> noticed some typos...
>
> Below is a quick summary of those concerns & questions. Over the coming
> days I hope to mark up the 3Sept07 draft comments fields with these
> concerns.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> ======================================
>
> Authoring tools definition:
> -> change “used” to “designed”:
> New text becomes: "Any software DESIGNED to create or modify content for
> publication..."
>
> Content definition:
> -> capitalize the first letter
>
> Contrast ratio definition:
> -> why in the first note does it say ratio ranges from 1 to 21? Why does
> it end at 21?
> -> also, what about a definition of “luminance”
>
> Decoration definition:
> -> Should this perhaps be only visual sensory experience? Or audio too?
> Should we note this?
>
> E&IT definition:
> -> it seems to me that by this definition, a copier is NOT E&IT, as the
> IT is embedded. Is this the intention?
>
> General Flash and Red Flash Thresholds definition:
> -> item #2 should replace “greater” with “less”, as in:
> ...The flashing is LESS than 50 Hz [replaces: below 55 Hz]; and...
>
> Menu definition:
> -> this needs to be scoped, perhaps just to telecom or “audio menus”. As
> it reads now, things like a collection of radio buttons would be
> considered a menu. Also, where is this term used in 508? three things to
> consider: instead of “Set of selectable options”, what about
> “Presentation of a set of selectable options”, or “Presentation of a set
> of user-selectable options”. But in either case, we should note that
> this is an audio/aural presentations
>
> Platform Accessibility Services definition:
> -> would like to replace “sometimes” with “commonly”, as in:
> ...Services provided by a platform enabling interoperability with
> assistive technologies COMMONLY in the form of accessibility APIs...
>
> Programmatically Determined definition:
> -> Shouldn't this be “Programmatically Determinable”?
>
> Real-time Text definition:
> -> do we really need the phrase “by a terminal” in this text?
>
> Terminal definition:
> -> do we really need the plural “or devices”? Is a terminal a plural
> object?
>
> Video Description definition:
> -> Is the second paragraph intended to be part of the definition?
>
> 1.1-C - Without Color Vision Deficits
> -> Text is not testable, and in fact doesn't map well to existing
> technical standards:
> “Products must provide at least one mode that allows access for people
> with color vision deficits” - but what does this mean in reality? We
> already say you cannot use color as the sole way of conveying info, so
> all modes should have that characteristic. Also, what sort of color
> vision deficits? There is a wide range of them...
> -> Compare this text with 3-A – Color, which states things much more
> clearly.
>
> 1.1-E – With Limited Hearing
> -> text says: “...at least one mode that allows access with enhanced
> audio...” What is “enhanced audio”? It isn't defined in the definitions.
> Is it just boosting the volume? Some sort of simple audio filter? As
> complex an audio filter as we have in modern digital hearing aids? What?
>
> 1.1-G – With Limited Reach, Strength, or Manipulation
> -> text says: “...and that does not require simultaneous actions...”
> This is directly covered in 2.1-C(2). Do we really need this to be
> duplicated in the FPC?
>
> 1.1-I – With Cognitive, Language or Learning Limitations
> -> Second word seems missing. Change “Product provide at least one
> mode...” to “Products MUST provide at least one mode...”
> -> Note further, in the discussion/rationale section, it claims Dr.
> Lewis put forth 3 features. He put forth 5. Three are addressed by our
> new 3-V provisoin (AT interoperability), one we already had, and the
> fifth is in advisory 3-X(1) Suppression of unneeded functions.
>
> 1.2-A – Closed Product Functionality
> -> This reads like an FPC. It is not clearly testable. I think it
> belongs in the FPC section
>
> 1.2-D – Pass Throughout
> -> This continues to have the same problem it had months ago (when I
> noted it back then). Virtually every computing device “transmits or
> conducts information or communication”, so this would apply to things
> like disk drive firmware and a huge host of other things that have no
> user input impact. It is nonsensical.
>
> 1.2-E – Audio Information
> -> Sounds like another FPC. I note it came from closed, so why “directly
> or via AT” in it as well? This is not testable and doesn't belong in the
> technical provisions
>
> 1.2-F – Visual Information
> -> Same comment as above. Another FPC, came from closed, has “directly
> or via AT”, and is not testable. It doesn't belong in the technical
> provisions.
>
> 1.2-H – Text size
> -> Incorporate the second "note" of 3-U as a note here as well, as this
> provision now covers a lot more than just the closed products (the SC
> that it came from)
>
> 2.1-C – Mechanical Controls
> -> I'm curious, where did the 2 second number come from? Is this
> essentially SlowKeys in disguise?
>
> 2.1-D – Touch Operated Controls
> -> sounds like a FPC, with “directly or through AT” in it. I'm concerned
> about testability of this provision... [Note: in the meeting earlier
> today we agreed to remove the "directly or with AT" text]
>
> 3-B – Contrast
> -> We should see if we can make this text more general, rather than
> limiting it to “electronic documents” and then having separate
> provisions (3-P & 3-Q) that talk about contrast for user interfaces.
>
> 3-G – Flashing
> -> This provision notes that it is a subset of 1.2-B Flashing. If so,
> why is it needed here? Seems redundant and removable.
>
> 3-I – Size, shape, location
> -> Should clarify that “Instructions” applies to instructions that are
> part of the user interface presentation, not printed documentation
>
> 3-J – Audio turnoff
> -> We should clarify the situation for web pages: better if the web
> browser had this responsibility, so web pages that played sound didn't
> have to explicitly include a 'turn sound off' button when the browser
> can do this function more universally (less burned on programmers to do
> this once in the browser). Perhaps this could be done in an advisory
> note...?
>
> 3-K – Reading Sequence
> -> See the text in 8.1-C Reading Order; that uses the phrase “logical,
> linear reading order”, vs. “a correct reading sequence”. I don't know
> what “correct” is. How can it be tested? Though I understand this text
> comes from WCAG, I find it difficult (and would prefer to use the 8.1-C
> text).
>
> 3-L – Repeated Blocks
> -> Better to use structure for this [I believe yesterday we agreed to do
> that...]
>
> 3-N – Information and Relationships
> -> This provision pretty clearly assumes it is talking about a document,
> but it doesn't mention it explicitly (and there, an XML/HTML document).
> In (2), (3), and (4) it directs the explicit use of “markup” to do
> things (all of which are covered in 3-V). This provision should either
> be removed as redundant, or scoped to explicitly apply to (web) documents.
>
> 3-O – User Interface Components
> -> Like 3-N, this is really about (web) documents; everything in it is
> covered by 3-V. I think we should either remove it as redundant, or
> scope to it web documents.
>
> 3-P – User Preferences
> -> Best placed right after 3-A Color, as this is really all about
> color/contrast preferences
>
> 3-Q – Color Adjustment
> -> Best placed right after 3-B Contrast, as this is really about color
> changes that can result in specific minimum contrast levels
> -> alternately place 3-P and 3-Q together right after 3-B
>
> 3-T – Keyboard Operation
> -> A long time ago this provision (or something like it) was scoped to
> systems that had a keyboard. Now it essentially says that something like
> an iPhone has to have a keyboard (or at least, have a UI operable by a
> keyboard). That doesn't make sense to me.
>
> 3-V – AT Interoperability
> -> Please note the final text “Note: This provision applies to forms in
> the software”. With that comment, 3-V subsumes the need for 3-O
>
> 4-A – Caption Playback
> -> In the “Material for inclusion in the additional notes document:”
> section, the 7th bullet says “Support options for altering the
> appearance of caption character edges”. What does this mean? What are
> some of the potential options? As an engineer, how can I know if I've
> done this?
> -> In the same section, 8th bullet says “Support the authoring and
> selection of the six caption services...”. What are these? I've never
> heard of this before.
>
> 5-B – Real-Time Text Reliability and Interoperability
> -> 5-C says you must have/support RTT. Saying it also in this provision
> is redundant (first sentence)
>
> 5-C – Voice Terminal Hardware and Software
> -> This structure is poor. Essentially it says: “Do A. If you haven't
> done A, do B.” Better to say: “You must either to A or do B (or do both)”.
>
> 5-D – IVR, Auto-Attendant and Messaging
> -> Text of item 1 says “All functions that are accessible to voice users
> must also be direct accessible to users of real-time text.” How do we do
> that for a voice-prompted menu? Has anyone prototyped this? We shouldn't
> put anything into a testable provision that we don't know how to do.
>
> 5-E – Caller and Status Information
> -> This says that products with visual interfaces that display status
> info must make the info available for TTYs among others. How do I make
> Skype's connection information available to a TTY? This provision is
> making assumptions about the device that don't match the text of the
> provision.
>
> 6-A – Synchronized Alternatives
> -> this is a very broad provision that applies to practically all media;
> 6-B and 6-C limits the scope in which alternatives must be synchronized.
> I think this provision doesn't belong and should be removed; certainly
> it contradicts 6-B(1) and 6-C(1).
>
> 6-B – Captioning and Transcripts
> -> (2) and (3) note that captions must be provided for things with
> concurrent audio. But really, don't we mean for concurrent spoken audio?
> Perhaps a nit, as you only caption speech, but...
>
> 6-C – Video Description
> -> I think (3) is too broad. Think of the situation of a recording of a
> video slide presentation. If the (accessible) slides are provided
> separately, and the speaker refers to each slide name/number when moving
> to a new slide, haven't we made this presentation accessible? Do we need
> to actually provide verbal descriptions of the slide text?
>
>
>
>
>
From: Gregg Vanderheiden
Date: Thu, Sep 06 2007 11:45 AM
Subject: Re: Review of , and questions & concerns with 3Sept07 TEITAC draft
Yes, Good catch. This is a problem.
This provision should have the "If the product is typically held up to the
ear during use..... "
on the front end. This was not meant to apply to speakerphones or to other
devices with headphone jacks.
We should also remove the word telecommunication since the next word is OR
so everything is covered anyway.
Kind of like "All apples or fruit must xxxx"
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Thursday, September 06, 2007 11:07 AM
> To: TEITAC Committee
> Subject: Re: [teitac-committee] Review of ,and questions &
> concerns with 3Sept07 TEITAC draft
>
> Hi Diane,
>
> Thanks for this pointer. I think this text points out a
> problem with our current draft 2.2-E(3). That text says:
> "All other telecommunications products or systems that
> provide a function allowing voice communication must provide
> a gain adjustable from the normal unamplified level to at
> least 20 dB above the normal unamplified level as measured in
> accordance with the provisions of the FCC regulation
> §68.317 for volume control. The volume at the normal
> unamplified level setting must also meet the requirement in
> FCC regulation 68.317."
>
> As the link that Diane posted makes clear, the FCC 68.371
> language directs vendors to measure audio level "through the
> receiver in the handset or headset of the telephone". The
> longer text is: "digital telephone complies with the
> Commission?s volume control requirements if the telephone is
> equipped with a receive volume control that provides, through
> the receiver of the handset or headset of the telephone, 12
> dB of gain minimum and up to 18 dB of gain maximum".
> Separate from whether the gain should stay at the 68.371
> level of 18 dB, or whether it increases to 20 dB, is the
> issue for computer-based VoIP solutions where the computer is
> sold separately from the voice chat program is sold
> separately from the headset. We can't place a burden on
> software like Skype that can only be measured through a
> headset that they don't control. And what of the computer -
> do we penalize the Dell laptop that Skype is running on if
> Skype doesn't expose via a software user interface a volume
> control that does 20 dB?
>
> So I think we need to change 2.2-E(3) to have language that
> firstly doesn't depend upon the 68.317 measurement technique,
> and secondly recognizes that software audio
> telecommunications products like Skype don't control all of
> the pieces and so provisions should only require of them
> things they can control.
>
>
> In an interesting way, this is essentially the same problem
> as we have with making the FPC language "usable with AT"
> something we test. As IT doesn't control AT - as Skype
> doesn't control the audio hardware in a DELL laptop or a
> Jabra headset - we cannot require it to do things it cannot control.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
> >
> http://a257.g.akamaitech.net/7/257/2422/05dec20031700/edocket.access.g
> > po.gov/cfr_2003/octqtr/pdf/47cfr68.317.pdf
> >
> > This should link you to the FCC reg. I'm fairly certain the
> > measurement of gain is acoustic, thus it will be dependent on the
> > speaker, headset, handset or whatever is used for output.
> >
> > Diane
> >
> > ----- Original Message ----
> > From: Peter Korn < = EMAIL ADDRESS REMOVED = >
> > To: = EMAIL ADDRESS REMOVED =
> > Sent: Wednesday, September 5, 2007 5:30:39 PM
> > Subject: [teitac-committee] Review of , and questions &
> concerns with
> > 3Sept07 TEITAC draft
> >
> > Hi guys,
> >
> > Just as we did for the last TEITAC meeting, running a handful of
> > products through the provisions to see what issues came up, I went
> > through the entire 3Sept07 draft, to see how this draft of the
> > language in total was working from our perspective. I found
> a number
> > of concerns, which I share below. It is interesting to note
> that even
> > though I participate vigorously in the Web & Software
> subcommittee, I
> > found things when looking at provisions in the context of
> the entire
> > document that I felt should be revised. Also, we heard from gov't
> > agencies and the States yesterday that they see an explosion of
> > provisions in these drafts compared with the 2001 edition - where
> > provisions are redundant or can be combined, I think it
> would be very
> > helpful. Finally, I also noticed some typos...
> >
> > Below is a quick summary of those concerns & questions. Over the
> > coming days I hope to mark up the 3Sept07 draft comments
> fields with
> > these concerns.
> >
> >
> > Regards,
> >
> > Peter Korn
> > Accessibility Architect,
> > Sun Microsystems, Inc.
> >
> > ======================================
> >
> > Authoring tools definition:
> > -> change ?used? to ?designed?:
> > New text becomes: "Any software DESIGNED to create or
> modify content
> > for publication..."
> >
> > Content definition:
> > -> capitalize the first letter
> >
> > Contrast ratio definition:
> > -> why in the first note does it say ratio ranges from 1 to 21? Why
> > -> does
> > it end at 21?
> > -> also, what about a definition of ?luminance?
> >
> > Decoration definition:
> > -> Should this perhaps be only visual sensory experience?
> Or audio too?
> > Should we note this?
> >
> > E&IT definition:
> > -> it seems to me that by this definition, a copier is NOT E&IT, as
> > -> the
> > IT is embedded. Is this the intention?
> >
> > General Flash and Red Flash Thresholds definition:
> > -> item #2 should replace ?greater? with ?less?, as in:
> > ...The flashing is LESS than 50 Hz [replaces: below 55 Hz]; and...
> >
> > Menu definition:
> > -> this needs to be scoped, perhaps just to telecom or
> ?audio menus?.
> > -> As
> > it reads now, things like a collection of radio buttons would be
> > considered a menu. Also, where is this term used in 508?
> three things
> > to
> > consider: instead of ?Set of selectable options?, what about
> > ?Presentation of a set of selectable options?, or
> ?Presentation of a
> > set of user-selectable options?. But in either case, we should note
> > that this is an audio/aural presentations
> >
> > Platform Accessibility Services definition:
> > -> would like to replace ?sometimes? with ?commonly?, as in:
> > ...Services provided by a platform enabling interoperability with
> > assistive technologies COMMONLY in the form of accessibility APIs...
> >
> > Programmatically Determined definition:
> > -> Shouldn't this be ?Programmatically Determinable??
> >
> > Real-time Text definition:
> > -> do we really need the phrase ?by a terminal? in this text?
> >
> > Terminal definition:
> > -> do we really need the plural ?or devices?? Is a terminal a plural
> > object?
> >
> > Video Description definition:
> > -> Is the second paragraph intended to be part of the definition?
> >
> > 1.1-C - Without Color Vision Deficits
> > -> Text is not testable, and in fact doesn't map well to existing
> > technical standards:
> > ?Products must provide at least one mode that allows access
> for people
> > with color vision deficits? - but what does this mean in
> reality? We
> > already say you cannot use color as the sole way of
> conveying info, so
> > all modes should have that characteristic. Also, what sort of color
> > vision deficits? There is a wide range of them...
> > -> Compare this text with 3-A ? Color, which states things much more
> > clearly.
> >
> > 1.1-E ? With Limited Hearing
> > -> text says: ?...at least one mode that allows access with enhanced
> > audio...? What is ?enhanced audio?? It isn't defined in the
> definitions.
> > Is it just boosting the volume? Some sort of simple audio
> filter? As
> > complex an audio filter as we have in modern digital
> hearing aids? What?
> >
> > 1.1-G ? With Limited Reach, Strength, or Manipulation
> > -> text says: ?...and that does not require simultaneous actions...?
> > This is directly covered in 2.1-C(2). Do we really need this to be
> > duplicated in the FPC?
> >
> > 1.1-I ? With Cognitive, Language or Learning Limitations
> > -> Second word seems missing. Change ?Product provide at least one
> > mode...? to ?Products MUST provide at least one mode...?
> > -> Note further, in the discussion/rationale section, it claims Dr.
> > Lewis put forth 3 features. He put forth 5. Three are
> addressed by our
> > new 3-V provisoin (AT interoperability), one we already
> had, and the
> > fifth is in advisory 3-X(1) Suppression of unneeded functions.
> >
> > 1.2-A ? Closed Product Functionality
> > -> This reads like an FPC. It is not clearly testable. I think it
> > belongs in the FPC section
> >
> > 1.2-D ? Pass Throughout
> > -> This continues to have the same problem it had months ago (when I
> > noted it back then). Virtually every computing device ?transmits or
> > conducts information or communication?, so this would apply
> to things
> > like disk drive firmware and a huge host of other things
> that have no
> > user input impact. It is nonsensical.
> >
> > 1.2-E ? Audio Information
> > -> Sounds like another FPC. I note it came from closed, so why
> > -> ?directly
> > or via AT? in it as well? This is not testable and doesn't
> belong in
> > the technical provisions
> >
> > 1.2-F ? Visual Information
> > -> Same comment as above. Another FPC, came from closed,
> has ?directly
> > or via AT?, and is not testable. It doesn't belong in the technical
> > provisions.
> >
> > 1.2-H ? Text size
> > -> Incorporate the second "note" of 3-U as a note here as well, as
> > -> this
> > provision now covers a lot more than just the closed
> products (the SC
> > that it came from)
> >
> > 2.1-C ? Mechanical Controls
> > -> I'm curious, where did the 2 second number come from? Is this
> > essentially SlowKeys in disguise?
> >
> > 2.1-D ? Touch Operated Controls
> > -> sounds like a FPC, with ?directly or through AT? in it. I'm
> > -> concerned
> > about testability of this provision... [Note: in the
> meeting earlier
> > today we agreed to remove the "directly or with AT" text]
> >
> > 3-B ? Contrast
> > -> We should see if we can make this text more general, rather than
> > limiting it to ?electronic documents? and then having separate
> > provisions (3-P & 3-Q) that talk about contrast for user interfaces.
> >
> > 3-G ? Flashing
> > -> This provision notes that it is a subset of 1.2-B
> Flashing. If so,
> > why is it needed here? Seems redundant and removable.
> >
> > 3-I ? Size, shape, location
> > -> Should clarify that ?Instructions? applies to
> instructions that are
> > part of the user interface presentation, not printed documentation
> >
> > 3-J ? Audio turnoff
> > -> We should clarify the situation for web pages: better if the web
> > browser had this responsibility, so web pages that played
> sound didn't
> > have to explicitly include a 'turn sound off' button when
> the browser
> > can do this function more universally (less burned on
> programmers to
> > do this once in the browser). Perhaps this could be done in an
> > advisory note...?
> >
> > 3-K ? Reading Sequence
> > -> See the text in 8.1-C Reading Order; that uses the
> phrase ?logical,
> > linear reading order?, vs. ?a correct reading sequence?. I
> don't know
> > what ?correct? is. How can it be tested? Though I
> understand this text
> > comes from WCAG, I find it difficult (and would prefer to use the
> > 8.1-C text).
> >
> > 3-L ? Repeated Blocks
> > -> Better to use structure for this [I believe yesterday we
> agreed to
> > -> do
> > that...]
> >
> > 3-N ? Information and Relationships
> > -> This provision pretty clearly assumes it is talking about a
> > -> document,
> > but it doesn't mention it explicitly (and there, an
> XML/HTML document).
> > In (2), (3), and (4) it directs the explicit use of ?markup? to do
> > things (all of which are covered in 3-V). This provision
> should either
> > be removed as redundant, or scoped to explicitly apply to
> (web) documents.
> >
> > 3-O ? User Interface Components
> > -> Like 3-N, this is really about (web) documents;
> everything in it is
> > covered by 3-V. I think we should either remove it as redundant, or
> > scope to it web documents.
> >
> > 3-P ? User Preferences
> > -> Best placed right after 3-A Color, as this is really all about
> > color/contrast preferences
> >
> > 3-Q ? Color Adjustment
> > -> Best placed right after 3-B Contrast, as this is really
> about color
> > changes that can result in specific minimum contrast levels
> > -> alternately place 3-P and 3-Q together right after 3-B
> >
> > 3-T ? Keyboard Operation
> > -> A long time ago this provision (or something like it)
> was scoped to
> > systems that had a keyboard. Now it essentially says that something
> > like an iPhone has to have a keyboard (or at least, have a
> UI operable
> > by a keyboard). That doesn't make sense to me.
> >
> > 3-V ? AT Interoperability
> > -> Please note the final text ?Note: This provision applies
> to forms
> > -> in
> > the software?. With that comment, 3-V subsumes the need for 3-O
> >
> > 4-A ? Caption Playback
> > -> In the ?Material for inclusion in the additional notes document:?
> > section, the 7th bullet says ?Support options for altering the
> > appearance of caption character edges?. What does this
> mean? What are
> > some of the potential options? As an engineer, how can I
> know if I've
> > done this?
> > -> In the same section, 8th bullet says ?Support the authoring and
> > selection of the six caption services...?. What are these?
> I've never
> > heard of this before.
> >
> > 5-B ? Real-Time Text Reliability and Interoperability
> > -> 5-C says you must have/support RTT. Saying it also in this
> > -> provision
> > is redundant (first sentence)
> >
> > 5-C ? Voice Terminal Hardware and Software
> > -> This structure is poor. Essentially it says: ?Do A. If
> you haven't
> > done A, do B.? Better to say: ?You must either to A or do B
> (or do both)?.
> >
> > 5-D ? IVR, Auto-Attendant and Messaging
> > -> Text of item 1 says ?All functions that are accessible to voice
> > -> users
> > must also be direct accessible to users of real-time text.?
> How do we
> > do that for a voice-prompted menu? Has anyone prototyped this? We
> > shouldn't put anything into a testable provision that we
> don't know how to do.
> >
> > 5-E ? Caller and Status Information
> > -> This says that products with visual interfaces that
> display status
> > info must make the info available for TTYs among others.
> How do I make
> > Skype's connection information available to a TTY? This
> provision is
> > making assumptions about the device that don't match the
> text of the
> > provision.
> >
> > 6-A ? Synchronized Alternatives
> > -> this is a very broad provision that applies to practically all
> > -> media;
> > 6-B and 6-C limits the scope in which alternatives must be
> synchronized.
> > I think this provision doesn't belong and should be
> removed; certainly
> > it contradicts 6-B(1) and 6-C(1).
> >
> > 6-B ? Captioning and Transcripts
> > -> (2) and (3) note that captions must be provided for things with
> > concurrent audio. But really, don't we mean for concurrent
> spoken audio?
> > Perhaps a nit, as you only caption speech, but...
> >
> > 6-C ? Video Description
> > -> I think (3) is too broad. Think of the situation of a
> recording of
> > -> a
> > video slide presentation. If the (accessible) slides are provided
> > separately, and the speaker refers to each slide name/number when
> > moving to a new slide, haven't we made this presentation
> accessible?
> > Do we need to actually provide verbal descriptions of the
> slide text?
> >
> >
> >
> >
> >
From: Andrew Kirkpatrick
Date: Thu, Sep 06 2007 3:15 PM
Subject: Re: Review of , and questions & concerns with 3Sept07 TEITAC draft
> 6-A - Synchronized Alternatives
> -> this is a very broad provision that applies to practically
> all media;
> 6-B and 6-C limits the scope in which alternatives must be
> synchronized.
> I think this provision doesn't belong and should be removed;
> certainly
> it contradicts 6-B(1) and 6-C(1).
I don't think that it necessarily contradicts b and c, I agree that
removing it isn't harmful since we added "synchronized" to b and c.
> 6-B - Captioning and Transcripts
> -> (2) and (3) note that captions must be provided for things with
> concurrent audio. But really, don't we mean for concurrent
> spoken audio?
> Perhaps a nit, as you only caption speech, but...
Actually you caption more than speech. Subtitles are just speech, but
captions also include non-spoken information. Generally it is true that
captions are mostly of speech, but not entirely.
> 6-C - Video Description
> -> I think (3) is too broad. Think of the situation of a
> recording of a
> video slide presentation. If the (accessible) slides are provided
> separately, and the speaker refers to each slide name/number
> when moving
> to a new slide, haven't we made this presentation accessible?
> Do we need
> to actually provide verbal descriptions of the slide text?
I agree - how about:
2) materials containing prerecorded video with concurrent audio must
provide synchronized video descriptions, or a separate text description
of the video, to convey any informational content of the video that is
not conveyed through other means.
3) materials containing live video must provide synchronized video
descriptions in real time to convey any informational content of the
video that is not conveyed through other means.
AWK
From: Larry Goldberg
Date: Thu, Sep 06 2007 6:25 PM
Subject: Re: Review of , and questions & concerns with 3Sept07 TEITAC draft
Andrew's rewrite sounds right to me.
- Larry
Andrew Kirkpatrick wrote:
>> 6-A - Synchronized Alternatives
>> -> this is a very broad provision that applies to practically
>> all media;
>> 6-B and 6-C limits the scope in which alternatives must be
>> synchronized.
>> I think this provision doesn't belong and should be removed;
>> certainly
>> it contradicts 6-B(1) and 6-C(1).
>
> I don't think that it necessarily contradicts b and c, I agree that
> removing it isn't harmful since we added "synchronized" to b and c.
>
>> 6-B - Captioning and Transcripts
>> -> (2) and (3) note that captions must be provided for things with
>> concurrent audio. But really, don't we mean for concurrent
>> spoken audio?
>> Perhaps a nit, as you only caption speech, but...
>
> Actually you caption more than speech. Subtitles are just speech, but
> captions also include non-spoken information. Generally it is true that
> captions are mostly of speech, but not entirely.
>
>> 6-C - Video Description
>> -> I think (3) is too broad. Think of the situation of a
>> recording of a
>> video slide presentation. If the (accessible) slides are provided
>> separately, and the speaker refers to each slide name/number
>> when moving
>> to a new slide, haven't we made this presentation accessible?
>> Do we need
>> to actually provide verbal descriptions of the slide text?
>
> I agree - how about:
>
> 2) materials containing prerecorded video with concurrent audio must
> provide synchronized video descriptions, or a separate text description
> of the video, to convey any informational content of the video that is
> not conveyed through other means.
> 3) materials containing live video must provide synchronized video
> descriptions in real time to convey any informational content of the
> video that is not conveyed through other means.
>
> AWK
>
From: Gregg Vanderheiden
Date: Thu, Sep 06 2007 8:20 PM
Subject: Re: Review of , and questions & concerns with 3Sept07 TEITAC draft
6-A does look redundant.
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Andrew Kirkpatrick
> Sent: Thursday, September 06, 2007 4:14 PM
> To: TEITAC Committee
> Subject: Re: [teitac-committee] Review of ,and questions &
> concerns with 3Sept07 TEITAC draft
>
> > 6-A - Synchronized Alternatives
> > -> this is a very broad provision that applies to practically
> > all media;
> > 6-B and 6-C limits the scope in which alternatives must be
> > synchronized.
> > I think this provision doesn't belong and should be
> removed; certainly
> > it contradicts 6-B(1) and 6-C(1).
>
> I don't think that it necessarily contradicts b and c, I
> agree that removing it isn't harmful since we added
> "synchronized" to b and c.
>
> > 6-B - Captioning and Transcripts
> > -> (2) and (3) note that captions must be provided for things with
> > concurrent audio. But really, don't we mean for concurrent spoken
> > audio?
> > Perhaps a nit, as you only caption speech, but...
>
> Actually you caption more than speech. Subtitles are just
> speech, but captions also include non-spoken information.
> Generally it is true that captions are mostly of speech, but
> not entirely.
>
> > 6-C - Video Description
> > -> I think (3) is too broad. Think of the situation of a
> > recording of a
> > video slide presentation. If the (accessible) slides are provided
> > separately, and the speaker refers to each slide name/number when
> > moving to a new slide, haven't we made this presentation accessible?
> > Do we need
> > to actually provide verbal descriptions of the slide text?
>
> I agree - how about:
>
> 2) materials containing prerecorded video with concurrent
> audio must provide synchronized video descriptions, or a
> separate text description of the video, to convey any
> informational content of the video that is not conveyed
> through other means.
> 3) materials containing live video must provide synchronized
> video descriptions in real time to convey any informational
> content of the video that is not conveyed through other means.
>
> AWK
>
From: Gregg Vanderheiden
Date: Fri, Sep 07 2007 9:35 AM
Subject: Re: Review of , and questions & concerns with 3Sept07 TEITAC draft
Yep.
Per discussion at meeting -- This would be fixed by adding
"products designed to be held up to the ear during use" (detachable headsets
and headphones not included)
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Thursday, September 06, 2007 11:07 AM
> To: TEITAC Committee
> Subject: Re: [teitac-committee] Review of ,and questions &
> concerns with 3Sept07 TEITAC draft
>
> Hi Diane,
>
> Thanks for this pointer. I think this text points out a
> problem with our current draft 2.2-E(3). That text says:
> "All other telecommunications products or systems that
> provide a function allowing voice communication must provide
> a gain adjustable from the normal unamplified level to at
> least 20 dB above the normal unamplified level as measured in
> accordance with the provisions of the FCC regulation
> §68.317 for volume control. The volume at the normal
> unamplified level setting must also meet the requirement in
> FCC regulation 68.317."
>
> As the link that Diane posted makes clear, the FCC 68.371
> language directs vendors to measure audio level "through the
> receiver in the handset or headset of the telephone". The
> longer text is: "digital telephone complies with the
> Commission?s volume control requirements if the telephone is
> equipped with a receive volume control that provides, through
> the receiver of the handset or headset of the telephone, 12
> dB of gain minimum and up to 18 dB of gain maximum".
> Separate from whether the gain should stay at the 68.371
> level of 18 dB, or whether it increases to 20 dB, is the
> issue for computer-based VoIP solutions where the computer is
> sold separately from the voice chat program is sold
> separately from the headset. We can't place a burden on
> software like Skype that can only be measured through a
> headset that they don't control. And what of the computer -
> do we penalize the Dell laptop that Skype is running on if
> Skype doesn't expose via a software user interface a volume
> control that does 20 dB?
>
> So I think we need to change 2.2-E(3) to have language that
> firstly doesn't depend upon the 68.317 measurement technique,
> and secondly recognizes that software audio
> telecommunications products like Skype don't control all of
> the pieces and so provisions should only require of them
> things they can control.
>
>
> In an interesting way, this is essentially the same problem
> as we have with making the FPC language "usable with AT"
> something we test. As IT doesn't control AT - as Skype
> doesn't control the audio hardware in a DELL laptop or a
> Jabra headset - we cannot require it to do things it cannot control.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
> >
> http://a257.g.akamaitech.net/7/257/2422/05dec20031700/edocket.access.g
> > po.gov/cfr_2003/octqtr/pdf/47cfr68.317.pdf
> >
> > This should link you to the FCC reg. I'm fairly certain the
> > measurement of gain is acoustic, thus it will be dependent on the
> > speaker, headset, handset or whatever is used for output.
> >
> > Diane
> >
> > ----- Original Message ----
> > From: Peter Korn < = EMAIL ADDRESS REMOVED = >
> > To: = EMAIL ADDRESS REMOVED =
> > Sent: Wednesday, September 5, 2007 5:30:39 PM
> > Subject: [teitac-committee] Review of , and questions &
> concerns with
> > 3Sept07 TEITAC draft
> >
> > Hi guys,
> >
> > Just as we did for the last TEITAC meeting, running a handful of
> > products through the provisions to see what issues came up, I went
> > through the entire 3Sept07 draft, to see how this draft of the
> > language in total was working from our perspective. I found
> a number
> > of concerns, which I share below. It is interesting to note
> that even
> > though I participate vigorously in the Web & Software
> subcommittee, I
> > found things when looking at provisions in the context of
> the entire
> > document that I felt should be revised. Also, we heard from gov't
> > agencies and the States yesterday that they see an explosion of
> > provisions in these drafts compared with the 2001 edition - where
> > provisions are redundant or can be combined, I think it
> would be very
> > helpful. Finally, I also noticed some typos...
> >
> > Below is a quick summary of those concerns & questions. Over the
> > coming days I hope to mark up the 3Sept07 draft comments
> fields with
> > these concerns.
> >
> >
> > Regards,
> >
> > Peter Korn
> > Accessibility Architect,
> > Sun Microsystems, Inc.
> >
> > ======================================
> >
> > Authoring tools definition:
> > -> change ?used? to ?designed?:
> > New text becomes: "Any software DESIGNED to create or
> modify content
> > for publication..."
> >
> > Content definition:
> > -> capitalize the first letter
> >
> > Contrast ratio definition:
> > -> why in the first note does it say ratio ranges from 1 to 21? Why
> > -> does
> > it end at 21?
> > -> also, what about a definition of ?luminance?
> >
> > Decoration definition:
> > -> Should this perhaps be only visual sensory experience?
> Or audio too?
> > Should we note this?
> >
> > E&IT definition:
> > -> it seems to me that by this definition, a copier is NOT E&IT, as
> > -> the
> > IT is embedded. Is this the intention?
> >
> > General Flash and Red Flash Thresholds definition:
> > -> item #2 should replace ?greater? with ?less?, as in:
> > ...The flashing is LESS than 50 Hz [replaces: below 55 Hz]; and...
> >
> > Menu definition:
> > -> this needs to be scoped, perhaps just to telecom or
> ?audio menus?.
> > -> As
> > it reads now, things like a collection of radio buttons would be
> > considered a menu. Also, where is this term used in 508?
> three things
> > to
> > consider: instead of ?Set of selectable options?, what about
> > ?Presentation of a set of selectable options?, or
> ?Presentation of a
> > set of user-selectable options?. But in either case, we should note
> > that this is an audio/aural presentations
> >
> > Platform Accessibility Services definition:
> > -> would like to replace ?sometimes? with ?commonly?, as in:
> > ...Services provided by a platform enabling interoperability with
> > assistive technologies COMMONLY in the form of accessibility APIs...
> >
> > Programmatically Determined definition:
> > -> Shouldn't this be ?Programmatically Determinable??
> >
> > Real-time Text definition:
> > -> do we really need the phrase ?by a terminal? in this text?
> >
> > Terminal definition:
> > -> do we really need the plural ?or devices?? Is a terminal a plural
> > object?
> >
> > Video Description definition:
> > -> Is the second paragraph intended to be part of the definition?
> >
> > 1.1-C - Without Color Vision Deficits
> > -> Text is not testable, and in fact doesn't map well to existing
> > technical standards:
> > ?Products must provide at least one mode that allows access
> for people
> > with color vision deficits? - but what does this mean in
> reality? We
> > already say you cannot use color as the sole way of
> conveying info, so
> > all modes should have that characteristic. Also, what sort of color
> > vision deficits? There is a wide range of them...
> > -> Compare this text with 3-A ? Color, which states things much more
> > clearly.
> >
> > 1.1-E ? With Limited Hearing
> > -> text says: ?...at least one mode that allows access with enhanced
> > audio...? What is ?enhanced audio?? It isn't defined in the
> definitions.
> > Is it just boosting the volume? Some sort of simple audio
> filter? As
> > complex an audio filter as we have in modern digital
> hearing aids? What?
> >
> > 1.1-G ? With Limited Reach, Strength, or Manipulation
> > -> text says: ?...and that does not require simultaneous actions...?
> > This is directly covered in 2.1-C(2). Do we really need this to be
> > duplicated in the FPC?
> >
> > 1.1-I ? With Cognitive, Language or Learning Limitations
> > -> Second word seems missing. Change ?Product provide at least one
> > mode...? to ?Products MUST provide at least one mode...?
> > -> Note further, in the discussion/rationale section, it claims Dr.
> > Lewis put forth 3 features. He put forth 5. Three are
> addressed by our
> > new 3-V provisoin (AT interoperability), one we already
> had, and the
> > fifth is in advisory 3-X(1) Suppression of unneeded functions.
> >
> > 1.2-A ? Closed Product Functionality
> > -> This reads like an FPC. It is not clearly testable. I think it
> > belongs in the FPC section
> >
> > 1.2-D ? Pass Throughout
> > -> This continues to have the same problem it had months ago (when I
> > noted it back then). Virtually every computing device ?transmits or
> > conducts information or communication?, so this would apply
> to things
> > like disk drive firmware and a huge host of other things
> that have no
> > user input impact. It is nonsensical.
> >
> > 1.2-E ? Audio Information
> > -> Sounds like another FPC. I note it came from closed, so why
> > -> ?directly
> > or via AT? in it as well? This is not testable and doesn't
> belong in
> > the technical provisions
> >
> > 1.2-F ? Visual Information
> > -> Same comment as above. Another FPC, came from closed,
> has ?directly
> > or via AT?, and is not testable. It doesn't belong in the technical
> > provisions.
> >
> > 1.2-H ? Text size
> > -> Incorporate the second "note" of 3-U as a note here as well, as
> > -> this
> > provision now covers a lot more than just the closed
> products (the SC
> > that it came from)
> >
> > 2.1-C ? Mechanical Controls
> > -> I'm curious, where did the 2 second number come from? Is this
> > essentially SlowKeys in disguise?
> >
> > 2.1-D ? Touch Operated Controls
> > -> sounds like a FPC, with ?directly or through AT? in it. I'm
> > -> concerned
> > about testability of this provision... [Note: in the
> meeting earlier
> > today we agreed to remove the "directly or with AT" text]
> >
> > 3-B ? Contrast
> > -> We should see if we can make this text more general, rather than
> > limiting it to ?electronic documents? and then having separate
> > provisions (3-P & 3-Q) that talk about contrast for user interfaces.
> >
> > 3-G ? Flashing
> > -> This provision notes that it is a subset of 1.2-B
> Flashing. If so,
> > why is it needed here? Seems redundant and removable.
> >
> > 3-I ? Size, shape, location
> > -> Should clarify that ?Instructions? applies to
> instructions that are
> > part of the user interface presentation, not printed documentation
> >
> > 3-J ? Audio turnoff
> > -> We should clarify the situation for web pages: better if the web
> > browser had this responsibility, so web pages that played
> sound didn't
> > have to explicitly include a 'turn sound off' button when
> the browser
> > can do this function more universally (less burned on
> programmers to
> > do this once in the browser). Perhaps this could be done in an
> > advisory note...?
> >
> > 3-K ? Reading Sequence
> > -> See the text in 8.1-C Reading Order; that uses the
> phrase ?logical,
> > linear reading order?, vs. ?a correct reading sequence?. I
> don't know
> > what ?correct? is. How can it be tested? Though I
> understand this text
> > comes from WCAG, I find it difficult (and would prefer to use the
> > 8.1-C text).
> >
> > 3-L ? Repeated Blocks
> > -> Better to use structure for this [I believe yesterday we
> agreed to
> > -> do
> > that...]
> >
> > 3-N ? Information and Relationships
> > -> This provision pretty clearly assumes it is talking about a
> > -> document,
> > but it doesn't mention it explicitly (and there, an
> XML/HTML document).
> > In (2), (3), and (4) it directs the explicit use of ?markup? to do
> > things (all of which are covered in 3-V). This provision
> should either
> > be removed as redundant, or scoped to explicitly apply to
> (web) documents.
> >
> > 3-O ? User Interface Components
> > -> Like 3-N, this is really about (web) documents;
> everything in it is
> > covered by 3-V. I think we should either remove it as redundant, or
> > scope to it web documents.
> >
> > 3-P ? User Preferences
> > -> Best placed right after 3-A Color, as this is really all about
> > color/contrast preferences
> >
> > 3-Q ? Color Adjustment
> > -> Best placed right after 3-B Contrast, as this is really
> about color
> > changes that can result in specific minimum contrast levels
> > -> alternately place 3-P and 3-Q together right after 3-B
> >
> > 3-T ? Keyboard Operation
> > -> A long time ago this provision (or something like it)
> was scoped to
> > systems that had a keyboard. Now it essentially says that something
> > like an iPhone has to have a keyboard (or at least, have a
> UI operable
> > by a keyboard). That doesn't make sense to me.
> >
> > 3-V ? AT Interoperability
> > -> Please note the final text ?Note: This provision applies
> to forms
> > -> in
> > the software?. With that comment, 3-V subsumes the need for 3-O
> >
> > 4-A ? Caption Playback
> > -> In the ?Material for inclusion in the additional notes document:?
> > section, the 7th bullet says ?Support options for altering the
> > appearance of caption character edges?. What does this
> mean? What are
> > some of the potential options? As an engineer, how can I
> know if I've
> > done this?
> > -> In the same section, 8th bullet says ?Support the authoring and
> > selection of the six caption services...?. What are these?
> I've never
> > heard of this before.
> >
> > 5-B ? Real-Time Text Reliability and Interoperability
> > -> 5-C says you must have/support RTT. Saying it also in this
> > -> provision
> > is redundant (first sentence)
> >
> > 5-C ? Voice Terminal Hardware and Software
> > -> This structure is poor. Essentially it says: ?Do A. If
> you haven't
> > done A, do B.? Better to say: ?You must either to A or do B
> (or do both)?.
> >
> > 5-D ? IVR, Auto-Attendant and Messaging
> > -> Text of item 1 says ?All functions that are accessible to voice
> > -> users
> > must also be direct accessible to users of real-time text.?
> How do we
> > do that for a voice-prompted menu? Has anyone prototyped this? We
> > shouldn't put anything into a testable provision that we
> don't know how to do.
> >
> > 5-E ? Caller and Status Information
> > -> This says that products with visual interfaces that
> display status
> > info must make the info available for TTYs among others.
> How do I make
> > Skype's connection information available to a TTY? This
> provision is
> > making assumptions about the device that don't match the
> text of the
> > provision.
> >
> > 6-A ? Synchronized Alternatives
> > -> this is a very broad provision that applies to practically all
> > -> media;
> > 6-B and 6-C limits the scope in which alternatives must be
> synchronized.
> > I think this provision doesn't belong and should be
> removed; certainly
> > it contradicts 6-B(1) and 6-C(1).
> >
> > 6-B ? Captioning and Transcripts
> > -> (2) and (3) note that captions must be provided for things with
> > concurrent audio. But really, don't we mean for concurrent
> spoken audio?
> > Perhaps a nit, as you only caption speech, but...
> >
> > 6-C ? Video Description
> > -> I think (3) is too broad. Think of the situation of a
> recording of
> > -> a
> > video slide presentation. If the (accessible) slides are provided
> > separately, and the speaker refers to each slide name/number when
> > moving to a new slide, haven't we made this presentation
> accessible?
> > Do we need to actually provide verbal descriptions of the
> slide text?
> >
> >
> >
> >
> >
From: Peter Korn
Date: Sat, Sep 08 2007 5:30 PM
Subject: Re: Review of , and questions & concerns with 3Sept07 TEITAC draft
Hi Whitney, Michele,
It sounds like we have a good proposal for a change to 6-B and 6-C, both
of which are marked as "Done" by the subcommittee and therefore, if I
understand correctly, out of the SC's hands. I believe Whitney that you
edited http://teitac.org/wiki/EWG:Draft_Sept_3 to include comments I
made that started this e-mail thread, and it appears that that document
is not open for general editing.
What is the process for taking rewrite suggestions like this one for 6-B
and 6-C and noting them on the wiki, as well as getting them into a new
draft?
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
> Andrew's rewrite sounds right to me.
>
> - Larry
>
>
> Andrew Kirkpatrick wrote:
>
>
>>> 6-A - Synchronized Alternatives
>>> -> this is a very broad provision that applies to practically
>>> all media;
>>> 6-B and 6-C limits the scope in which alternatives must be
>>> synchronized.
>>> I think this provision doesn't belong and should be removed;
>>> certainly
>>> it contradicts 6-B(1) and 6-C(1).
>>>
>> I don't think that it necessarily contradicts b and c, I agree that
>> removing it isn't harmful since we added "synchronized" to b and c.
>>
>>
>>> 6-B - Captioning and Transcripts
>>> -> (2) and (3) note that captions must be provided for things with
>>> concurrent audio. But really, don't we mean for concurrent
>>> spoken audio?
>>> Perhaps a nit, as you only caption speech, but...
>>>
>> Actually you caption more than speech. Subtitles are just speech, but
>> captions also include non-spoken information. Generally it is true that
>> captions are mostly of speech, but not entirely.
>>
>>
>>> 6-C - Video Description
>>> -> I think (3) is too broad. Think of the situation of a
>>> recording of a
>>> video slide presentation. If the (accessible) slides are provided
>>> separately, and the speaker refers to each slide name/number
>>> when moving
>>> to a new slide, haven't we made this presentation accessible?
>>> Do we need
>>> to actually provide verbal descriptions of the slide text?
>>>
>> I agree - how about:
>>
>> 2) materials containing prerecorded video with concurrent audio must
>> provide synchronized video descriptions, or a separate text description
>> of the video, to convey any informational content of the video that is
>> not conveyed through other means.
>> 3) materials containing live video must provide synchronized video
>> descriptions in real time to convey any informational content of the
>> video that is not conveyed through other means.
>>
>> AWK
>>
From: Mike Paciello
Date: Mon, Sep 10 2007 2:40 PM
Subject: Re: Review of , and questions & concerns with 3Sept07 TEITAC draft
Peter -
Thanks for your input. Jim and I will be meeting tomorrow with the other EWG
members to devise a reasonable and balanced process. We will inform the
committee immediately following our meeting.
Regards,
Mike
Mike Paciello
Cell: +1.603.566.7713
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: Saturday, September 08, 2007 7:23 PM
To: TEITAC Committee; Michele Budris; Whitney Quesenbery
Subject: Re: [teitac-committee] Review of , and questions & concerns with
3Sept07 TEITAC draft
Hi Whitney, Michele,
It sounds like we have a good proposal for a change to 6-B and 6-C, both
of which are marked as "Done" by the subcommittee and therefore, if I
understand correctly, out of the SC's hands. I believe Whitney that you
edited http://teitac.org/wiki/EWG:Draft_Sept_3 to include comments I
made that started this e-mail thread, and it appears that that document
is not open for general editing.
What is the process for taking rewrite suggestions like this one for 6-B
and 6-C and noting them on the wiki, as well as getting them into a new
draft?
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
> Andrew's rewrite sounds right to me.
>
> - Larry
>
>
> Andrew Kirkpatrick wrote:
>
>
>>> 6-A - Synchronized Alternatives
>>> -> this is a very broad provision that applies to practically
>>> all media;
>>> 6-B and 6-C limits the scope in which alternatives must be
>>> synchronized.
>>> I think this provision doesn't belong and should be removed;
>>> certainly
>>> it contradicts 6-B(1) and 6-C(1).
>>>
>> I don't think that it necessarily contradicts b and c, I agree that
>> removing it isn't harmful since we added "synchronized" to b and c.
>>
>>
>>> 6-B - Captioning and Transcripts
>>> -> (2) and (3) note that captions must be provided for things with
>>> concurrent audio. But really, don't we mean for concurrent
>>> spoken audio?
>>> Perhaps a nit, as you only caption speech, but...
>>>
>> Actually you caption more than speech. Subtitles are just speech, but
>> captions also include non-spoken information. Generally it is true that
>> captions are mostly of speech, but not entirely.
>>
>>
>>> 6-C - Video Description
>>> -> I think (3) is too broad. Think of the situation of a
>>> recording of a
>>> video slide presentation. If the (accessible) slides are provided
>>> separately, and the speaker refers to each slide name/number
>>> when moving
>>> to a new slide, haven't we made this presentation accessible?
>>> Do we need
>>> to actually provide verbal descriptions of the slide text?
>>>
>> I agree - how about:
>>
>> 2) materials containing prerecorded video with concurrent audio must
>> provide synchronized video descriptions, or a separate text description
>> of the video, to convey any informational content of the video that is
>> not conveyed through other means.
>> 3) materials containing live video must provide synchronized video
>> descriptions in real time to convey any informational content of the
>> video that is not conveyed through other means.
>>
>> AWK
>>
WebAIM is an initiative of:
