Thread Subject: Re: 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.

From: Gregg Vanderheiden
Date: Fri, Sep 07 2007 9:35 AM

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

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