- From: Ian Jacobs <ij@w3.org>
- Date: Fri, 11 Dec 1998 21:18:28 -0500
- To: w3c-wai-ua@w3.org
- Message-ID: <3671D274.E69F08AF@w3.org>
WAI UA WG Face to Face
Cambridge, MA
11 December 1998
Chair: Jon Gunderson (JG)
Scribe: Ian Jacobs (IJ)
Participants:
Olivier Borius (OB)
David Clark (DC)
Chuck Hitchcock (CH)
Jutta Treviranus (JT)
Kathy Hewitt (KH)
Daniel Dardailler (DD)
Glen Gordon (GG)
Bill Kilroy (BK)
Wilson Craig (WC)
Marja (MK)
Charles (CMN)
Denis Anson (DA)
Tom Wlodkowski (TL)
Chuck Oppermann (CO)
Harvey Bingham (HB)
Wendy Chisholm (WAC)
Markku Hakkinen (MH)
Judy Brewer (JB)
Agenda: http://www.w3.org/WAI/UA/1998/12/wai-ua-f2f-information
WC: Where are companies like Henter-Joyce being represented
in the guidelines?
JG: Early on, the concept of independent vs. dependent user
agents. What should each type support.
DD: Prefer the distinction between "mainstream" and
"specialized". We should put most of our efforts into
ensuring the accessibility of mainstream browsers.
Specialized user agents already know what to do
(it's their bread and butter).
WC: There are inherent conflicts in defining both
assistive tech vendors and mainstream browsers as
user agents.
DA: Does it make sense to say that the user agent
does the rendering and to say that the assistive
technology controls the user agent.
DC: Not always about providing the information,
but about providing the hooks so that assistive
techs can provide the information.
DA: Things that provide access to the rendered
information are assistive technologies.
JT: Talking about rendering muddies the waters.
I prefer dependent/independent definitions.
IJ: Editors introduced distinction, but haven't
developed it sufficiently.
WC: Fix 1.1 (where terms used inconsistently).
DD: To me, Jaws or Webspeak are independent because they
have a knowledge of the markup. It's an implementation
detail that they don't parse themselves.
JT: I don't think the analogy is quite correct.
CMN: We all know what we mean, and we want to use
the concept in the guidelines, but don't have a neatly
worded definition yet.
CO: I like Glen's characterization the best. Assistive
technology sits on UA and provides access to it. How
it does it is irrelevant. Doesn't include PWWebspeak
because they can take care of themselves. Any screen
reader has to rely on underlying technology that
the user may or may not have. PWWebspeak provides
that technology (though it uses the IE renderer). But
PWWebspeak is a self-contained application.
DD: There are two axes: mainstream vs. specialized
and dependent/independent.
JG: How can an agency claim conformance to these
guidelines? Perhaps specialized browsers would claim
conformance in a different way than mainstream
browsers.
CO: This group not formed because we had a lot
of complaints about PWWebspeak.
DC: So what is our audience. What are they comfortable
with and what do they need?
DD: I agree with both Jon and Chuck. Why don't we
say up front that our primary audience is mainstream
browsers. Apply, of course, also to specialized
user agents.
JT: Guidelines may also be a blueprint for how
all types of user agents will communicate (interface).
Therefore important to define who's who and what
communication takes place.
DA: Significant different between mainstream browsers
and specialized. The guidelines should help UAs
be as mainstream as possible.
CMN: Worries me to think that some browsers can be
used by everybody and some cannot.
JG: Need to identify classes of UAs so that we can
define requirements and responsibilities. Need to
formulate appropriate strategies and educate
companies.
/* Conformance */
IJ: Proposes a conformance in which
1) Conformance to three sets (Pri 1/2/3)
DA: I like the proposal that Ian doesn't like.
1) Conformance to all Pri 1 first.
CO: Compliance important
1) Techniques for developers
2) Comply to guidelines
Possibly conflicting goals.
Concept of priority (if it were up to me). Either
"required" or "recommended" (two priorities rather
than three). You either do it or
you don't. Give people notice by making a recommendation
first, then a requirement later.
I also advocate a series of WAI documents (say, every
18 months).
KH: Define conformance in terms of Priority one items.
They need to be relevant to industry. The document
became unuseful. (Lots of priority ones, wasn't
sure why so many Pri 1). Would think that the guidelines
would be more of a bell curve: small set Pri 1, lots
of Pri 2, fewer Pri 3. Need to be more careful about
what we label Pri 1.
<span class="action">Action KH:</span> Send comments to list.</span>
CMN: One problem with the recommendation-to-required
track is that this document is meant to address
problems now. Document should say "You must do this."
Whether now or later, it still must be done. It's
important now.
DD: Not just an issue of priorities. A lot list of
Pri 1 may mean that the granularity has to change.
I agree with CMN in theory. But there is also the
market and the implementation has to be part of the
loop. Guidelines can't be wildest dreams.
CO: We need techniques to be as specific as possible
(lots of techniques ok, useful to developers).
Want to be told which attributes of HTML need to
be supported. Not just support HTML 4.0.
(to CMN:) Technology changes. What may be a problem
now may not be a problem in the future. "Don't use
tables" may be true now, but in the future, may
not be a problem.
IJ: Discussion of distinction between techniques
in guidelines document vs. elaboration of
techniques in techniques document. Conformance
with respect to normative list of techniques
as expressed in the guidelines document.
DC: Back to question of dependent/independent. Must
describe Pri 1 techniques in terms of "alone" or
"in conjunction with" other technologies.
CO: Apply priorities to problems, not solutions.
That does not discount the fact that there are
better ways than others to accomplish certain
things.
DC: Want to avoid reverse engineering to get
the job done. Don't want to force impractical
solutions.
DA: Hook must be provided, but hook must also
be used.
JG: W3C must educate so that developers are aware
of these hooks.
WAC: Back to conformance...Have these discussions
happened in other groups.
KH: (referring to DA's comment): Native vs.
Assistive support. If we provide hooks, we've done
our jobs.
GG: Mainstream browsers may not do the right thing
for users. Not through fault of their own. Right
thing may not be clear.
DD: Some people may not have opportunity to
get the technology.
IJ: Economics, bandwidth, platform, ...
CO: Cross-disability benefits of assistive
technologies. E.g., multiple table renderings could benefit
a wider audience.
JG: Summarizing
1) Who's the audience for the document? Industry developers
but also consumer groups (purchasing products that
conform to guidelines).
2) Pri 1's are most important for conformance.
<span class="resolved">Resolved</span>:
Compliance/Conformance will be to
Priority 1 techniques as expressed in the guidelines
document. There is further work to establish
what class of user agent must conform to which
of those techniques.
Add note: Guidelines are the goals. May be other
ways to meet them, but these are the techniques
chosen by this WG. In other words, you don't
conform to "Accessibility", you conform to the
document.
<span class="action">Action editors:</span> Draft exact
wording of this conformance statement.
Microsoft agrees with reservations and waits to review
pending proposal.
JT (Chair of AU WG): Sounds good.
WAC (Editor of PAGL): Sounds good.
DC: Writing a spec and defining the bar
for passing the spec are distinct.
CO (to Denis): Difficult to say "We comply with
a technique" since we may not agree with it or
think we can do it better. (Comparison iwth
Windows Logo guidelines). How do we identify
the problems and fix them?
JT: Is the word "technique" appropriate? Perhaps
too strongly implies "how". Would "demonstrable
outcome" be better?
3) We need to ensure that industry concerns
remain in the loop of decision-making.
DC: You can't design for all people. Trying to
accomplish something for one group may
contradict with the needs of another.
--
Document:
http://www.w3.org/TR/1998/WD-WAI-USERAGENT-19981112
--
Accessible design principles and practices.
Technique 3.1.1:
CMN: Change wording to "available through control
mechanisms that are not device-dependent."
DA: What if they use third-party assistive techs?
Does this count.
IJ: Recognizes that "all functionalities" is big.
KH: Please underline that access to a button
not important, but the functionality offered
by the UA is available.
CO: 3.1 Collapse all three.
IJ: 3.1.3 important on its own
IJ: "general principles of design" is vague.
CO: So is "is accessible".
DC: 3.1.2 raises an issue mentioned at the last
face-to-face. I'd like to see more about mnemonic
or simplistic or logical aids. These techniques
are oriented toward visual disabilities and we
must also consider cognitive as well. I also
think it contradicts 3.1.1
WAC: What worries me about 3.1.1 is that the functionalities
must be <strong>readily available</strong>, not just
available. Customization is important and I should
be able to customize for all functionalities.
DA: Must be functionally accessible as well as
just accessible.
KH: I agree in theory with the comment about "readily
available" (you don't want to have to go through
5 submenus).
IJ: Users must be able to customize their environment.
Also must have access to all functionality. Together,
you get what you want.
DA: 3.1.3. Installation procedure must have equivalent
accessibility as the application.
CMN: The installation procedure is part of the UA
and therefore are subject to the guidelines.
IJ: Is 3.1.2 useful?
DC: Strike it. Covered in 3.1.1
WAC: Part of 3.1.2 is:
1) Use standard platform toolkits (so that
screen readers pick up).
2) Accessibility API.
CO: Why should standard platform toolkit be used?
DD: Use platform toolkits (which may be made
accessible) for consistency.
WAC (modifying): Whatever tool you use, when you paint text,
it should be painted as text, not an image.
JT: Point Wendy making is that there are a lot of
things not covered in 3.1.2 (including her point
above). Standards will improve accessibility.
CO: Re "how text is drawn". Lowest level: pixels
drawn. Higher level - glyph (still an image).
Higher level -index to glyph. Higher level -
Unicode reference. Always an image. Applications
are starting to paint their own image, bypassing
OS hooks. Difficult to define "how text is drawn".
It's a moving target.
This is a very difficult problem: making a user
interface and one that's accessible. Not the goal
of this group (making content accessible). There
are plenty of good references about how to make
an interface accessible.
Don't ignore the issue, just don't want to spent
a lot of time on this issue. Use platform guidelines.
Let's worry about HTML-specific issues.
CMN: Technique 3.1.2 circular with guideline.
WAC: The principles exist out there and we need
to point to them obviously.
IJ: Careful - AU Guidelines will be referring to
this document and how to make UA interface accessible.
WAC: We also refer to UAs in the PAGL.
/* Break */
3.4 Provide documentation about accessibility features.
Ian: Comment about "is accessible" again. What does
"is accessbile".
WAC: Should this be in a central reference document?
JB: Two things we're planning:
1) Need for common definitions for all three documents
2) Need for assistive technology document. (Publish
as a W3C NOTE)
DC: In this particular instance, "alternative formats"
would be more appropriate than "is accessible".
CMN: I don't agree.
DD: For 3.4 (1, 2, 3). Clarify online "product"
documentation.
DA: For many products, the HOWTO install must be
accessible before the software itself is installed.
IJ: "is accessible" used rather than refer to
specific formats or renderings.
GG: Comments refer to application as well as
installation. Define as one unit up front.
CO: This is not an HTML issue, but a general
application issue.
HB: Is there a convention that we could live
with (e.g., a README file). Appropriate for
UAs to depend on a simple text format.
IJ: Both documentation and installation are
important entry points and should be in the document.
JB: People frustrated that features not more
readily available, even if they exist in
a tool. People not very good at finding that
information.
CW: Jaws installation - if all you have to do
to install is put your CD in and hit enter,
a braille one-liner.
JG: Is there consensus that the techniques in 3.4
cover the issue adequately.
HB: Time element. Installation is a one-time event.
Day to day use and accessibility in those scenarios
a very different thing.
TW: 3.4.4 is a priority 2. I have concerns about
that based on the education project we're working
with. Teachers deal with a lot of users, some
more savvy than others. This should be a priority 1.
DA: Look at the definitions of Pri 1 vs. Pri 2. If
someone shows you the features (even though you
don't read the documentation), you can still use
the features. Therefore should be a Pri 2.
TW: Problem with educators is that they don't know
about these features. And their students don't.
Too many people don't know someone who can
show them the features.
KH: I agree with Denis. Shouldn't the education role
be carried out by the EO WG? Difficult to go
into a class of functionalities and ask what meets
an accessibility concern. There may be things users
use to meet their needs that we might not think
of immediately as "accessibility features".
Marja: Following reasoning of "someone else could do
it", all the techniques could be Priority 2.
Very useful to provide scenarios (e.g., for blind
users). Show how features used in combination.
DD: How do we define accessibility feature. Is it
a view of the documentation or a separate part of
the document.
CMN: To follow up on DD - If your documentation is
incomplete, the tool is inaccessible. If complete,
but poor quality, doesn't mean inaccessible (just
poor). Telling people how to organize their
documentation is a hairy issue. Should be Priority 2.
MH: There needs to be some general scenarios about
how the tool can be used (whether or not you
have a disability). This would be very helpful.
IJ: Suggest integrating accessibility comments throughout
documentation, but this would be a recommendation.
Realistically, need to provide a separate section that
gives a few of the most important entry points.
DC: We shouldn't make the decision about integration
or separation. Just to make the information readily
available. For 3.4.4 - don't talk about "a section,"
just readily available.
JB: HTML 4.0 different than a UA. Helpful in HTML 4.0
to sprinkle references. For a UA, however, very
useful to have a separate section. Readily available
is most important.
DA: Recall definition of Priority 1. Documentation
is a "difficult" issue, not impossible.
Section 3.5
How to let people know there are keyboard commands
available?
CO: How is 3.5.1 different from 3.4.4?
JG: Former is specific instance of latter.
IJ: Highlight keyboard access since so important.
DA: Providing shortcuts in a menu may not be
so useful if you can't get to menu.
IJ: Use OS standard mechanisms.
Section 6.2
Use and provide accessible interfaces to
other technologies.
CMN: Techniques that begin "Otherwise" feel
like they should be collapsed.
IJ: Propose collapsing 6.2.2, 3, 4.
CO: 6.2.1 same as 6.2.5 (or could be made).
CO: 6.2.4 Pet peeve. Define "standard". Propose
revise "use operating system-provided interfaces".
DD: Bugs in 6.2.3 wording.
/* Ian: move 6.2.2 to top of list */
Section 3.2
CMN: 3.2.1 and 3.2.2 are potentially in conflict.
What if conventions are inaccessible. Propose
mergining into one sensisble technique.
DC: (from on high of soap box): Don't forget
cognitive issues.
JG: "mouse-only" to "device-independent".
IJ: "Wheverever possible". Fuzzy. Remove where
possible, or enumerate.
DC: Command-line only interface would probably
be inaccessible in the broader scheme.
CO: 3.2.1 and 3.2.2 covered in 3.1.
CO: 3.2.3. Microsoft has strong
disagreement with priority of that.
CO: 3.2.4. Good idea. Add comment - use the
platform-provided mechanism if available.
JB: Don't think 3.2.3 should be Priority 1.
CO: 3.2.5
We have a "restore defaults" button. This doesn't
allow you to switch back and forth. Your settings
are gone. Not too many applications let you do this.
CMN: Push 3.2.1 and 3.2.2 covered by 3.1. 3.2.3 could
be broadened to allow users to configure control
of the browser (Pri 1). More general than keyboard
access. 3.2.5 is a Pri 3. Won't be strung up for
not doing it. Don't see a reason for taking it out.
CO: Does "restore defaults" count for 3.2.5?
CMN: Not entirely.
DA: Microsoft's OS itself lets you do 3.2.5.
CO: Add to 3.2.5 "allow this by logging in as
a separate user".
DC: Accessible command keys. 3.2.3 should be Pri 2.
CMN: Allowing reconfiguation of controls seems
a general high priority featured.
3.2.5-7 seem candidates to be collapsed.
/* Will discuss with editors off line */
CO: If the developer will do something different,
should be a different technique. When pieces
are included, push them into guidelines.
DA: If this section of the document is the only
place where keyboard controls are discussed,
must be priority 1. If discussed elsewhere more
specifically, could be pri 2 here.
CO: The ability to configure keyboard access for
every application is a worthy feature. Don't think
should be priority 1 technique since it doesn't
prevent access. Few people yelling at MS "Can't
use your browser since I can't remap the keys."
JB: Few cases where inability to remap would
make access impossible.
CO: This is Bryan Campbell's big issue. He's a big advocate
of the ability to remap and we've discussed extensively.
JB: Chair, how do we proceed to establish the priority
level.
<span class="action">Action CMN, CO, KH, DA:</span> Will
reexamine priority of 3.2.3.
Section 3.3
IJ: "equivalent textual representation" means "captions".
Does this mean "alt text" as well? How to explain what
this means to novice readers?
CH: Please clarify whether "equivalent textual
representation" also means "alt text".
<span class="action">Action editors:</span> Clear this
up.
/* CO discusses rendering of dimensions of alt text
vs dimensions of image */
WAC 3.3.7: Generalize scripts to programmatic objects
and include applets.
CO: In addition to scripts, add techniques related
to the loading and execution of embedded objects.
IJ: The definition of "programmatic objects" is
important.
GG: Is the browser obligated to tell the server
that it's not capable of loading the objects.
DD: Not an issue.
DD: 3.3.9. How is this different from 4.1.14.
IJ: Rendering different from ability to turn on/off.
WAC: Suggest referring to related techniques.
CO:
3.3.2: Define "video". A lot done through embedded
objects. The UA may not be aware of what's happening.
In the case of animations, the UA is aware of this.
(3.3.5, 3.3.6).
3.3.3: UA not available of what's going on in an OBJECT.
MH: I have the same comment. From the user's perspective,
animated gifs, etc. all considered "video". I want
to turn off "moving stuff".
DC: Goes back to independent vs. dependent UAs. This
is a guideline for dependent UAs.
DD: Qualify all of these with "when the user agent knows".
Also, if you can turn off embedded content (3.3.7)
you accomplish the goal of turning of video effects.
IJ: Proposed: "Where knows" and give details in
techniques document (e.g., bgsound).
CMN: Version 2 of IE has menus "Play sounds", "Play
video".
WAC: Knowledge about object types through MIME types.
IJ: That goes in the techniques document.
WAC: Propose "blinking, moving, or changing" content.
CO: 3.3.4. Does this include alt text? (see above)
3.3.5. Make into "animated and blinking text".
3.3.8. On/Off support for style sheets. Need
to separate support for author and user
style sheets. Don't think turning off
is a priority 1.
3.3.9. This is a rendering issue. Disagree with
Priority and placement.
/* Lunch */
HB: Should turn/off be all or nothing? Would like
to turn off images generally, but select one
and view it. Add this to intro of section 3.3
DC: That would be a P2.
DA: Features may interfere with "or enhance" (add this)
accessibility.
JG: Distinguish user from author style sheets.
WAC: 3.3.8 should be Pri 1 since style sheets can
do crazy things.
DC: Not a given who has final control (user or author).
Priority 1 is that user have final say.
DD: There are things you cannot change with a user style
sheet but that you can turn off, e.g., with a button.
E.g., knowing which property I've used to achieve
a certain effect may not be obvious.
KH: Did some investigation about this for IE 5 and
became clear that this is not a simple problem.
E.g., positioning. If I turn off positioning when
there are layering effects, what happens?
WAC: IE3 used to allow turn on/off. Netscape allows
you to do it. It's possible. Positioning without
style sheets means use document order.
IJ: UA shouldn't be responsible for choosing a
"next best rendering". Should just render in
document order in general case.
KH: What problem is solved by 3.3.9? Assistive techs
are solving the problem quite adequately.
JB: A lot of discussion about this at "Closing the
Gap". If you are using a screen reader, frame issues
may be solved by a screen reader.
WAC: Small screen issue. Learning disability problems
as well.
KH: I can understand cognitive issue. Mobility issue
solved with navigation. What is it priority 1?
MH: How do access keys interact with different frames?
Can't access navbar type frame when focus in a separate
frame.
KH: Haven't tried this out.
/* Discussion postponed until CO returns */
JG: For 4.1, change to "override author styles
and adjust user agent defaults".
DA: If you use that language, would that mean that
using the "return to default settings" mean factory
defaults?
IJ: "Default values" means the value when the UA
starts. Want to be able to change that dynamically,
without changing default value. (e.g., Using 27 point
font currently for the purposes of a projector,
but want 8point when I start up emacs tomorrow in
the office). Don't agree that should be "adjust"
UA defaults.
DC: Change by profile?
CNM: Profiles are Pri 3 currently.
4.1.5/6: Change "foreground and background color" to
"presentation" (e.g., could use underlining, different
voice quality, background music, etc.)
CO: That's a big request. Configurability of the focus
rectangle is a big request we get. Can use CSS
to accomplish the goal of changing focus. /* Ian
proposes discussing this in the techniques document */
Propose separating techniques for different
conditions.
DC: Make media independent.
<span class="action">Action Editors:</span> Propose
wording that is slightly more general, but doesn't
bind UAs for media types not supported. Move specific
examples to techniques document.
Re: 4.1.7 Is there a need to control background
images? Doesn't the ability to turn on/off background
images?
Resolved: Add to 3.3 turn on/off background images
and remove from 4.1.
Marja: What's the fallback presentation?
CO: Good question! Rules as I understand them:
1) if no background image, is it set in HTML?
2) if set in CSS, use that.
3) otherwise use OS background color. This may
be overridden.
DA: Foreground and background imaging must be
independent.
JT: Whatever is done to establish background color,
is this covered in the spec?
JG: Yes.
DA: 4.1.8. Users may want to control rate of
animation to have access to the information (and
not just turn on and off).
CO: I've spoken with several programmers about this.
In case of animated GIF, UAs know rate, can scale and
stop it. Changing frame rate not a Pri 1. Stopping
would be a Pri 1.
DC: Not sure I agree. If showing the action is
critical to getting the content, turning off
alone doesn't suffice. Information must be
conveyed elsewhere.
CO: I agree. Important, but not a must. Billboards,
for example that change quickly.
WAC: For ads, I agree. But for information critical
to understanding (e.g., how to tie a bow-tie), I think
it should be a priority one.
DA: One of the applications of animations is to
demonstrate processes. If the object is embedded,
the mainstream browser may not need to provide
the control. But the functionality must exist.
IJ: Proposed clarification: "When the UA knows
how to access the animation rate for an
object." (to 4.1.8).
CO: We're working on adding a metric related to
"reading rate".
IJ proposal:
2) Add wording that control by rendering agent
3) Add wording that control when UA has access
to those particular properties of the object.
1) Is animation rate the only issue?
GH: People will need to start and stop
as well.
CO: Pause. Start means from beginning.
HB: Need to be able to backup a little as well.
CO: Proposed user interface for animations: allow
tabbing to animations. Use keys to control
animation. Also could have vcr-style controls
(speed up, slow down).
MH: How do users know what's what and what rules
apply to different types of objects.
DC: I think we're going too far down the
implementation path. Just allow users to have
final control over active media objects.
CO: That's a problem regardless today.
MH: The issue is consistency of controls.
Vcr-controls exist for other types of objects.
DC: Is consistency covered by referring to
OS standards?
CO: Possibly. But real-audio may not use the
same keys.
<span class="action">Action editors:</span>
Propose wording about (1) per image control
[what priority] and global control [what priority]
(2) control of rate Pri 1 (3) control of
start, stop, pause, continue priority 2 (4)
support by rendering agent.
DA: Consistent controls would be a priority
2 concern, not priority 1 in any case.
IJ: Seems outside the scope of this group.
DC: Careful about choosing priorities. Certain
groups, but not others, may benefit/suffer due
to priority choices.
Same issues apply to 4.1.9 as to 4.1.8.
Do same issues apply to audio issues?
WAC: For 4.1.12 change "a specific" to "among available
tracks."
CMN: The user agent is the one rendering the information.
MH: Yes, but from the user's perspective, you share
the same view. Need consistency across media types.
HB: Should the user profile include information about
what users never want.
DA: Don't want to have to turn off styles when
racing against a seizure.
CO: 4.1.10 will be changed to include "when UA aware
of rate".
/* Note: CSS2 may be used to specify volume */
CO: Why is control of volume priority 1?
DA: Use the external volume control.
JB: Not all boxes have a manual volume control.
CO: Shouldn't be a priority 1 since other ways
to get at content.
DA: The information would not be available to
some groups.
CO: 4.1.12: Should be stricken.
CMN: 4.1.13 Need also to control pitch/tone. This is a CSS2
property as well.
CO: Is supporting "CSS2 aural" a priority 1?
CMN: If you're not using CSS to control them, but
still rendering speech, still need to provide
a means to control.
DC: Rendering agent is the entity that must be
controllable.
CO: Put in 4.1 : Here are the techniques for these
things. If you support these things, do them.
Otherwise, don't have to.
IJ: We say that in techniques document.
CH: About speech. What does "support" for speech
mean? Rendering? Highlighting? Text to speech?
CO: "SAPI" is MS's speech API.
CH: What's the UA in this case?
CO: The browser is not aware of some of the things
going on.
MH: I'll speak for the UA... want to
be able to speed up, slow down, etc. But need
to be clear about recorded speech or synthesized
speech. Affects what you need to eo.
CMN: If call it techniques for automatically generated
speech, where browser is creating speech, and you want rate,
volumn, and pitch control, could put it into techniques for
rendered audio. Would provide the clarity.
DA: If talking about recorded speech, that's just audio.
Then could do pitch maintenance by audio playback.
MH: with pitch rendering
HB: user profiles may need to pass info to UA.
CO: I would shy away from profiles. Platforms should support
these things. These are cross-component issues.
Info should be sharable.
Proposed: Be able to change the pitch
of audio files. What priority?
JT: Would this exclude a group?
JB: Yes, e.g., those hard of hearing.
CO: I recognize its importance. But should it
be a priority 1.
WAC: Issue of captions again. Can't assume that
they will be provided. Will be helpful and
necessary if captions not provided.
DA: Recall that priorities not based on number
of people but on locking people at.
JB: You're locking out (1) aging population
(vision + hearing loss) and (2) deaf/blind
community with range loss. Yes, I believe it
locks some groups out.
CO: Each decision will lock out some community.
Have to make decision about benefitting greatest
number of users as well.
DD: Not all techniques are related to media perception.
Some are related to convenience, etc. So not true
that all would become Priority 1.
JB: Multimedia is a difficult area for the growing
Web. Also an area with not as much advocacy
from different groups.
/* Where did 4.1.15 and 4.1.16 come from?
IJ: Paul A. / Scott L */
CO: Several issues
1) Need to control window size based on user need
2) Need to control window position based on user need
Should allow users to turn off automatically spawned
windows.
WAC: PAGL says don't use popup windows. But also relies
on UAs in the future to warn users.
DD: I consider 4.1.15/4.1.16 to belong more to the
section on the user interface. Distinguish that
which happens due to HTML from that which happens
due to interface (e.g., warning). How do you
warn users that a window will pop up? By popping
up a window?
CO: This is also a security issue. I want an option
that says "prompt me" when new windows are requested.
Tech 1: Turn off entirely
Tech 2: Prompt before.
Windows pop up all the time. UAs have to deal with them.
Don't make this a Priority 1 unless we tell vendors
of other applications to do this as well.
MK: Any way for UA to know which windows are available?
CMN: No "windows" menu as in Word.
CO: If a new windows popup, a few things happen
a) Programmatic things happen. Screen readers have
access to that information.
b) In windows, you get info somewhere in the environment.
GG: I basically agree with CO assuming there's
an accessibility aid available. But if not, problem
not addressed.
CMN: Propose Pri 2 to 4.1.15/16. Also shift to section
three.
CO: Proposed interface: Allow/Don't allow/Prompt.
Don't know that we would allow resizable.
CO: Spawning windows part of Javascript environment.
What can one do?
CMN: You can disable resize, scroll, etc.
DD: Style guide should say "If you press a button,
a dialog will appear". There's a convention in the
way menus are displayed to give clues to the user.
In HTML, value of "_blank" for the "target" attribute
means UA might open a new window.
IJ: Add to techniques document - for target="_blank" UA
should inform the user according to the user's
customization.
JT: One reason windows are annoying is for people
with visual/cognitive limitations. Not necessarily
that they don't want them, just that they don't
want to be disoriented by them.
JB: These are not usability guidelines. These
are accessibility guidelines.
CO: Another real-world example - HTML in email
messages. Your browser is started up and
disorients as well.
IJ: How much should "usability" and "accessibility"
be mixed?
JB: Procurement requirements ususally based
on accessibility needs, not usability.
/* Break 3pm */
/* Daniel on minutes */
Table issues: please consult 9 Dec minutes.
JG: Issue is relationship to screen reader (read cross col)
Issue also with Table used as layout tool
2 kinds of Table: layout, tabular
Different levels of linearization are possible
(based on presence of markup or not, kind of table)
If not done native in the browser, the assistive
technology can use an API to implement it (DOM, DHTML,
MSAA). But APIs are not yet standard across browsers
CMN: Can also use CSS positioning
JG: Another concept relevant to table navigation is the
point of regard. People want to move up and down,
row or col, switch directions, etc.
IJ: Users want cell level access: reformating and navigation
are two ways of doing that. That's P1. More navigation
improves contextual access (where you are, what column
header is relevant). The goal is to define level of
table access to prioritize and decide what's done
natively or not.
DA: Surrounding information is more than header.
IJ: linearization is not the only way.
DA: linearization is sometimes not approriate (Statistics
data for instance)
CO: Keyboard Navigation not the ideal solution
GG: Given the bits on the screen, wants the information
in the structure, and the other way
IJ: mapping backward harder (DOM people working on it)
CO: Going from x,y to the element was added in DHTML.
MH: looking at daisy book, it's not just for table, need
information of navigation significence.
DA: Navigation long table/document thru element is not
adequate, you need to be able to go thru larger chunk.
IJ: lots of navigation schema in the guidelines:
hierarchical, thru list, by link, etc. Not eveything is
there , but there's lot.
DA: May want to navigate arbitrary element.
MH: in webspeak, we added the ability thru preference to
declare which elements are navigable (maybe done thru
some style sheet syntax)
JG: one question is what AT wants
DC: Search functionality gives an example of things where
the browser
DA: both cell rendering and and cell context information are
vital, regardless how it's done.
CO: Some screen readers use API to provide cell by cell
access.
IJ: still want to push the most important thing: individual
cell information rendered as block, which sounds easy
and already supported in the code.
CO: don't want to say it's easy when talking about about
new development.
IJ: CSS1 supports block display on all element
CO: maybe already solved
IJ: implementation question, not guidelines
DD: Jaws does table unrolling because IE doesn't do it
JB: how many screen readers do table unrolling
JG: overall, what strategy will solve accessibility the best
way: done by browser or done by AT ?
WAC: IE Powertool is an in-between approach that works fine.
JG: similar to running a user script on load that would
improve the layout
DA: issue of who would write the scripts
JG: WAI may help?
CH: I favor nagivation and native linearization thru simple
user action
GG: like the idea of running script doing linearization
that user or AT could fire.
JT: responsibility is shared between browser and AT
CO: maybe have two different techniques: P1 make cell
information available, P2: Provide this information
natively and possibly navigation as well.
JT: General navigation issue: Keyboard-based selection
of anything in an HTML doc that isn't a link/active
element?
/* Ian on minutes */
DD: CSS has the 'display' property with 'block' value. From
the CSS2 spec: "Conforming HTML user agents may ignore the
'display' property." In the WAI guidelines, we could make it
a (Pri 1) requirement. Thus, for table linearization,
simple application of CSS.
CO: CSS is always a great way to implement stuff.
CO: Re selection copying. We get this request all the
time. Two ways: 1) Search for particular text.
2) Save page as text file, open in text editor
to use selection copy.
MH: Word 97 has feature on scrollbar to allow
navigation by element.
DA: Point of highlighting text is not to retype it.
If you have to copy to find box to highlight and
then to copy is pointless.
/* On W3C post-REC support */
JB:
1) For WAI in general, there has always been
a recognition of the need for promotion and
encouragement of implementations based on
accessibility improvements. WAI IPO set
up for this reason, among others.
2) At W3C in general, movement to improve
post-Recommendation follow-up and promotion.
Historically, advocacy done by other organizations.
But now W3C management feels the need to
support "life after Rec". In particular, the CSS
Working Group has pushed hard by creating
(or monitoring the creation of) test suites,
validation tools, etc. the SYMM WG is in a similar
position of monitoring support.
JG: Would WAI be responsible for educating assistive
technology developers?
JB: Could be part of WAI's responsibility. Also
push to have assistive technologies move towards
standardization of interfaces.
CO: Agree that our job would be easier if there
were standard interfaces to plug into. What more is
needed?
JB: Not everyone uses Windows. To answer Jon's
question, yes, could fit into WAI's scope. However,
not only WAI's responsibility.
CO: There are similar standards on Unix/Apple systems, but
few tools that require it.
JG: Provide code for platforms.
JB: It could be well within WAI's scope to educate
developers for important accessibility issues. We
don't have the ability or role to enforce. The WG
must bear that in mind when writing the guidelines.
No guarantee from W3C to enforce.
CO: Lack of participation from other browser manufacturers
is indicative of the uphill battle.
DC: Must be as frugal as possible with our priority
1s. We have to be realistic if we want these guidelines
implemented.
CO: Discussion on the IG list lately about the PAGL
being too much.
HB: Any time a Pri 1 shows up. How do we justify it?
JB: At WAI EO WG meeting this morning, discussion about
the "AIEE, it's huge!" thread on the mailing list.
Upshot of discussion in that group: the stuff in the PAGL
needs to be there. The detail needs to be there. The
PAGL WG used to have a checklist and this would be
valuable again. We want the content, but need different
ways to slice it.
KH: My personal opinion that the guidelines represent
a wish list more than industry reality. Would like
to reduce number of Priority 1 items. If Pri 1, should
a tech be native if affects a large number of users?
No one wants "all the stuff" pushed on them, either
mainstream browsers or assistive techs.
DC: Laws vs. Regulation. We're doing regulation without
defining the basic laws. If we come up with the laws
that have to be met ...
JB: I'm concerned about the analogy you're proposing.
This is not a legal or regulatory environment. This
is a voluntary, consensus-based WG.
IJ: Not "wish list" but expression of accessibility
requirements. Industry concerns are built-in by
virtue of this discussion.
DA: I agree with DC that we must be frugal with
our Priority 1s. But don't want to fall into the
trap of "easy vs. hard." The issue is "accessible
vs. inaccessible".
JB: I too like "Frugal with Priority 1". We've been
talking about screen readers a lot, but there
are other disabilities involved that would not
have screen readers.
CO: Process questions
1) Yes, this WG should be collecting, validating,
and quantifying data. And then working with developers
saying "here's the wish list, what's practical?"
"If you don't this, you're impacting this set of people."
Look at 5.1.3.: Provide user with info about number of
tables in a document.
JB: If we create a wish list first and browser
manufacturers say what's practical, then browser
manufacturers could say "zero", and others will
follow.
IJ: Describes how stuff gets in the document. Editors
take what shows up on the list. WG is responsible
for reviewing the document. Editors do the best
they can to glean information and proposed text
from the list. And we announce changes at publication.
CO: What's happened is that someone says something and
it goes into the document.
DA: As part of the WG, you can say "I don't think
that should be a priority 1 technique" and start
a dialogue about how people or groups of people
might be shut out.
JB: If an item comes in from the list is it automatically
a priority 1?
IJ: No. It may be if similar techniques are rated that
way.
JB: This process is *not* clean and easy. The result
should be a list of requirements that are realistic.
Life gets harder towards the end of the document.
The WG cannot put off the prioritization of the
techniques any longer.
JG: Do we have the techniques that we want?
JG: We've talked about tables and navigation. How
would we rewrite guidelines?
IJ: Providing "cell level info" is not enough. It's
just part of the document like any other piece.
DC: Is our purpose to provide a developer checklist
or to have general working premisses we want
followed. I say this because the last draft
too ambiguous and we decided we wanted it more
broken out since that would make it more quantifiable.
Now, broken out, people are protesting it's too
specific (or long). This indicates we have opposite
and conflicting goals.
JT: We had the same discussion in the AU group. We
shouldn't be too draconian to allow vendors to
distinguish their products. We should say that
this is what we need and why we want it. We will
know that you've met this need if this happens.
JG: How do we do this for tables?
CO: Three levels
1) Requirements gathering and prioritization.
WG solicits input, does usability studies. Gets
input about what problems exist. This WG presents
some information that I don't hear from users.
2) Potential solutions and triage of requirements
Work with developers here.
3) Actual solutions
This is announced in developer press releases
after the product comes out.
I think the WG doesn't work enough at Level 1. The
goal of the WG is to produce a document at Level 2.
So:
1) Pri 1: Access to table information
2) Pri 2: Unrolling of tables
IJ: Chuck, why didn't we hear the requirements that
you've gleaned.
CO:
1) Lack of time
2) Discouragement because ideas have been booed down.
In general, chorus of boos when MS makes proposals.
E.g., my developer says it's hard to unroll
tables in code. A limit to how much arguing
one wants to do.
JB: UAGL WG has not been chartered to do usability
studies (nor has funding). Also, if you have
your own collection of barriers, please share
these with the WG.
Dave made important points about "back and forth"
editing - more specific to less specific. But
CO's proposal would slow us down again. I know
a lot of people would like to finish quickly.
For tomorrow's discussion, people are encouraged
to speak to as much detail as possible.
I think that CO's comments can still be resolved
with some refocusing of the document. I hope they
do not reflect complete dissatisfaction with the
document.
DA: About the ease/difficulty of unrolling tables.
Distinguish barriers to implementation from
barriers to accessibility. Unless you're coding,
you don't know the barriers to implementation. But
we can't say "that's not a problem" if people
don't have access.
DC: My one concern about the Priority approach
does not take a cross-section of different
disability populations. Focuses on the most vocal
groups with the largest number of users. That
concerns me.
JB: Please note that cross-disability was called
for last week. Also for people to examine
priority levels. I hope we will also get more
participation out of this.
JT: Re linearization of tables - The need is
not linearization.
Received on Friday, 11 December 1998 21:19:22 UTC