Re: Editorial fix for FAST

Some more - btw, I looked to see if I could create PRs for this but 
can't find repo.

# 1.5 "The first is truly generic needs, requirements users have to 
access and use content <del>such as</del> /in order to/ perceive and 
understand it, and should be stable over time."

# 1.5.1 Should "Where user needs are suspected but known, related work 
may expand the inventory through research when feasible." be "
Where user needs are suspected but /unknown/, related work may expand 
the inventory through research when feasible."

# Should this section cover multimedia streams?Control of audio? Routing?

e.g

1.5.3Applicability of Needs

  * Content (static, dynamic, multimedia)
  * Controls (buttons, fields, etc.)
  * Input indicators (mouse, keyboard cursors)
  * Signals (non-actionable state indicators)
  * Alerts (dialogs, alarms, etc.)

#In 'On request location indicator' what does "5.8 Sufficient quality 
(e.g. volume, direction, clarity, frequency) for audio feedback.)" refer 
to? Is the 5.8 a ration, or reference to some standard? It's not clear.

# [User Needs] For adjustability of output, there should be a section on 
'panning' - for screen reader (and other)users to place sounds in 
different places on the sonic stage. Worth discussing with Janina.

  * Positioning of text alternatives, captions etc, may also be
    something to add.
  * The ability to stop or control motion (a la vestibular disorders).

#Some comments about the presentation of user needs. It is rather a lot 
for a reader to take in. Would using a show/hide accordion type thing be 
helpful?

#What about links to vids that demonstrate the user need?

# Could there be a Wizard or walk thru for the reader - Something like 
"If you are designing tech type A - then this set of user needs x will 
apply", or "If you are designing tech type B - then this set of user 
needs y will apply"? I like the idea of sets also. Grouping/chunking 
depending on what is being built. Rather than the kitchen sink type 
approach can be overwhelming for non-experts etc.

# Interesting that "Don’t override accessibility features

  * Preferences, e.g., typeface, color, size, layout, volume, contrast…)
  * Preferences return to default state when switching users [not web?]

Could be phrased as 'Support A11y preferences" a positive statement :-)


#  For 3.1 Ways to Meet User Needs - I'd include OS level preference 
support (see below).

User needs need to be analyzed for how they can be met. The following 
ways of meeting needs are currently understood:

  * Author design
  * Author technical implementation
  * User agent accessibility support of standard features
  * User agent support of author-implemented accessibility features
  * Assistive technology support (including accessibility API mediation)
  * Operating System level prefences (such as text size, global contrast
    settings)

HTH

Josh

--
Emerging Web Technology Specialist/A11y (WAI/W3C)