- From: Charles McCathieNevile <charles@w3.org>
- Date: Wed, 3 Mar 1999 09:58:07 -0500 (EST)
- To: WAI AU Guidelines <w3c-wai-au@w3.org>
Raw minutes from Tuesday's meeting. These will also be converted to HTML
and linked from the Group page as soon as possible
Charles
--Charles McCathieNevile mailto:charles@w3.org
phone: +1 617 258 0992 http://purl.oclc.org/net/charles
W3C Web Accessibility Initiative http://www.w3.org/WAI
MIT/LCS - 545 Technology sq., Cambridge MA, 02139, USA
start 8.55
WL: less intro text would be good
action editors to write 2.3 intro covering content, structure, management
GR Not having section intros allows faster technical interpretation
WL: can these general principles go into abstract
IJ you need some intro to each set of checkpoints
CMN Charles Oppermann was keen to have more intro to checkpoints
WL It's in the abstract
IJ, no it isn't all there
JT Where should text now in 2.3 go?
DD should be shortened and kept
JR should professianlly written go into a checkpoint?
WL can the intro notes be distinguished from the checkpoints?
CMN already happens in the 'official (= online)' version
KB, JB arrive 8.55
section 2.4
DD: I woul like to merge 2.4 with either 2.2 or 2.5
WL: It is logical under 2.2
DD: Supporting things includes the emphasis on doing it right.
CMN: I agree with daniel
DD: It is a lower priority version of the same
IJ: Why would it go here?
CMN: Because providing encouragement is part of supporting the accessibility features
DD: It helps to reduce the number of guidelines
JT: We don't want to lose anything
WL: Discouraging bad practise is part of supporting accessible practise
JR: is it?
CMN/WL Yes
JR: You can provide technical support without encouraging.
CMN: Yes, but it doesn't split as far as a guideline
//little section of minutes from Ian
WL: Publishing differs from saving (don't interrupt
saving, interrupt publishing).
KB: 2.5.2 seems like stating the obvious.
MD: Might be a plausible for leaving this in the document:
common sense not widely distributed. Structured editing,
for example - usability nightmare, but some people
decided philosophically that this was a good thing. The
situation with accessibility is analogous: not allowing
saving an inaccessibility nightmare is a usability problem
//thanks Ian
md; common sense ain't common. it is a good idea to have editors which wouldn't let you construct incorrect programs. this
caused a serious reuseability problem. it is not the case that you have a better tool if you can't save an inaccessible
document
dd; i want to keep this, but move it to configuration - there we should say that fundamental operation should be
controlled. or maybe in the checking.
wl; i want to second what he said about innoculation. this illustrates that we are not proposing draconian measures to
mess up the environment. at the same time there should be something i the language which emphasises why this should not be
published. - your own space and public space are different
dd; they are not different
jb; in some casses a person gets a 95per cent finished document and publishes it. I don't think there is a difference
JT: we're going in circles. So we move this to checking or configuring.
checking? 4 configure? 4
JB: should be both...
RESOLVED: move checkpoint 2.5.2 into both 2.7 and 2.8
GR: "or postponed"? How is this different from asking if you want to save changes? There are times when something will pop
up and honk at you.
KB I don't think a prompt is the same as 'postponing'.
MD I want to have the feature, but I want it to be configurable?
2.4.1
what do we mean by highest priority?
IJ are we talking about 2 different accessible solutions? Isn't it already a no-no to present inaccessible options
DD I thought this was more to ask for the alt text immediately, rather than hiding it. So maybe there shothis should split
in two. Make accessible practise visible, and promote highest priority.
IJ are the specific practices which should be checkpoints eg when you insert an image get ALT text
BK maybe should be techniques
IJ Maybe, but there are some things which seem like techniques, but are so important that they need to be checkpoints.
Most visible isn't clear
KB: Example: image editor - first dialog has height, width, filename, and then you need to click 'advanced' for Alt text
IJ: Yes, but the wording is still not verifiable
GR: Ensure that there is a place for accesible features on the main screen
BK rather than buried under dialogues or something
GR: Ensure that options presented include accessibility options
IJ: This sounds good - it is verifiable
JR you are assuming a dialogue box or something
IJ not yet.
GR: This can happen in anything.
JT: Should be one of the first things you see - should be at the top,
JB say 'prominently include aceesibility options.
CMN: Wherever options are presented, accessibility ones should be there
WL at the same level
IJ what does 'the same level mean'
GR: Means that these are base functionality features.
KB I don't see why this doesn't presently meet the criteria?
IJ I don't know what most visible means
JR: example: in frontpage you can use font, or CSS to change colours. in frontpage, the toolbar option uses font. to use
CSS you have to go through a process.
IJ that is an example that doesn't apply, because one is inaccessible. Where there are a comparable set, you can order
them. perhaps: Include both required and optional accessibility features in interface components.
JT: doesn't make a checkpoint
IJ needs wordsmiting.
JT this got at the emphasise and make it easy to do.
GR: i think it might be easier to make checkpoints for each of the three strands than trying to get this encapsulated.
JT 3 things: needs to be few steps. needs to be visible. needs to be at the top of the list of choices
ACTION kynn - rewrite this and send to list. Add default configuration.
GR: having 3 checkpoints makes it easier to get all the steps implemented.
IJ: between same semantics, choose the most accessible first
WL: does it say that I have to put alt before filename?
IJ: No. only deals with order where there are two ways to do the same task.
2.6
RESOLVED 2.6.1 goes
JR: 'these processes are hidden form the users view and may create inaccesible content' - same thing
IJ: and RTF is a markup language
BK suggest we rename the guideline itself. I see it as having to do with HTML produced by a conversion
JT: I think it is for anything that removes acessible structure
JB I thnk there are a few things where the name of the guideline doesn't match. I think we should talk about structure or
content. There are 3 things. don't strip stuff out, don't add junk, and don't alter. should we look at specific examples?
WL 2.1.2 ends on wrong word
CMN I think 2.6.3 is the crux, and should be generalised boyend accessibility
KB: We could express this as positive
IJ generally i prefer positive
DD in this case I prefer negative - Never remove is stronger than Always preserve.
JR: maybe we should reword the intro to encompass changing and importing.
GR: do you want to cover both here Daniel?
DD I think we can cover both. Sylvain might have an example, because Domino translates on the fly from a lotus format -
apparently the native format has accessibility info, but the conversion doesn't use it.
JT I think the guideline is clear and succinct, and there are lots of instances where ths happen. Can we express that in
the introduction.
IJ 2.2 says do the right thing. 2.6 says 'don't do the wrong thing'. Can they be merged?
JT I think we need to be clear about this.
DD As much as i like less guideline, I like this guideline
JT I think we need to have a principle
KB I agree that we need it because this goes back to what is the problem? It addresses a big problem that a lot of editors
have.
RESOLVED: change intro to cover the various bits
JT Should we change the checkpoints, to have Judy's don't add, don't strip, don't alter
GR: Should we include changing the DTD?
KB 2.6.3 sounds like it should tell you about that. Changing DTD is a structural change
GR: I don't think it would hurt ot explicitly state something like
CMN: I don't think we need to say don't add. DTD is in techniques
DD: don't strip is part of don't alter
KB How about changing a 3.2 DTD to a 4.0?
JB: Key is notification
KB: 2.6.2 - should preserve any markup because it might be necessary for accessibility but not recognised
DD: I think we need to understand these issues. If I create the perfect tool it does HTML 4.0. If I keep it for HTML 5.0,
do I apply 2.6.2, or do I extend DTD?
KB: The problem is that we are identifying specific things and everything else can be removed
IJ we will have a set
KB we have a set for now, but next year it may not be complete.
JR: How about only removing structure you know is not for accessibility?
IJ: How do you know if it is not for accessibility? Where possible we should be able to refer to a common set of things.
JT: Clarification - this is not User Agent, and we have talked about what we mean by accessibility features, but Kynn's
point is that if that changes, there are things that are not covered by this.
KB Even if it looks wrong, then it shouldn't touch it
DD: HTML 4.0 we changed the map content model. in HTML 5 it will be different - it will be better If I use HTML 5 model
and validate on HTML 4, it won't validate. I know better, so I should have the last say.
JT: I don't want to have an editor stopped from removing junk I don't want.
KB: I am saying that it won't know what accessibility needs
BK: we shouldn't be encouraging changing markup - it is impssible to make an authoring tool that knows everything
IJ eg I write HTML 4, and your 3.2 tool strips out stuff editing it to validate it as 3.2. I wouldn't ask the HTML 3.2
tool to know about html 4.0
DD: I think the tool should validate - it modifies the markup to make it valid.
CNM: There are two ideas here:
1) We don't want the tool to remove markup without asking.
2) we do want a tool that takes crap and produces css plus html 4.0.
kynn's point is valid - we can't define the set of things a tool should not change.
a tool should not change structure or markup representation without checking
with the author.
kb - remove automated from 2.6.3 add to 2.6.2 to give 'never automatically remove or modify structure that is necessary
for accessibility
CMN: we don't have an exhaustive set. we have 2.2 to cover accessibiltiy. So the need for this guideline is to talk about
not making the changes under the hood - ask the user if they want to make them
JT: But the user may not know what are accessible changes
KB that's what context-sensitive help
GR: I don't have a problem tih doing this
JT are you assuming that all authors are going to know what are the access bits are, or that they are going to read all
help
GR: I don't see that it is an either/or question
IJ: User Agents ignore what they don't recognise. Can we ask authoring tools to change this behaviour? We are asking them
to change for the future, which is what is contrary to the way that forward-looking languages are developed.
JR: You make a good point. Problem is that many Tools ignore what they don't know. Maybe we should have a checkpoint which
says ignore what you don't know.
IJ there are tools which we want, which can convert bad to good. The rest, to survive, need to ignore.
JR if you can have a bad to good then you can have a doesn't matter to doesn't matter
GR I thik it would collect all the unknown elements, and present you with a summary of changes
JR we are trying to use automation, not gathering stuff.
GR I as an author would prefer the information
JT so what is the default
DD - leave it in. Configure to fix broken stuff.
cmn - perhaps have a checkpoint - ignore what you don't understand.
that's an important part of this checkpoint, but we also ask that you
work to a valid dtd. Leaving in bad stuff is mutually exclusive with
a valid dtd.
JT: suggested by Kynn: rather than referring to content for accessibility, we say never remove content. We cannot defince
the structure for accessibility, but we want to be able to improve accessiblity. You can prompt the user to say yea or
nay, but that takes the emphasis from developer to user.
IJ with WCGL we had two sections - one big and one small. Here we have the same - I propose we should put them in a single
section. We discussed the two topics in the intro to the section (see WCGL intro) and then we had the single run of
contents.
DD I wanted that for WCGL but I don't want it here.
//Ian minutes from here:
AU Face-to-Face at Lotus
2 March 1999
Chair: Jutta Treviranus (JT)
Team Contact: Charles McCathieNevile (CMN)
Jan Richards (JR)
Kynn Bartlett (KB)
Gregory Rosmaita (GR)
William Loughborough (WL)
Judy Brewer (JB)
B. K. DeLong (BKD)
Sylvain Galineau (SG)
Ian Jacobs (IJ)
Daniel Dardailler (DD)
Mark Day (MD)
Acronyms:
WCGL (Web Content Guidelines)
UAGL (User Agent Guidelines)
AUGL (Authoring Tool Guidelines)
----
------
11am Ian on notes.
/* All guideline/checkpoint numbers refer to intermediate
document produced on 2 March for Working Group */
Re: Guideline 2.6
WL: Most of what we've been talking about is
more in the realm of techniques than checkpoints.
IJ: Don't leave information up to reader when you can
be specific. W3C Recs should not be ambiguous
or leave open to interpretation when it's possible
not to.
Resolved two checkpoints for 2.6:
a) Don't remove markup that is
known to promote accessibility.
b) Don't remove unrecognized markup without alerting
the author.
/* Discussion as to whether "a" is obvious/necessary */
Also: Summary of structural changes, formerly 2.6.3 is
a technique of how to alert the author.
Still required: list of techniques.
-----
Guideline 2.7
DD: Delete Note in this section and refer to Guideline 2.8.
CMN: Proposed: Switch 2.8 and 2.7 [No.]
DD: Guideline 2.7 text: Provides ways of checking and
correcting all inaccessible markup
/* Can we talk about "inaccessible markup"? */
IJ: I think that it's difficult to say "inaccessible
markup is not what's in the WCGL".
CMN: A rough definition is "what breaks the WCGL".
KB: Inaccessible markup includes at least that which breaks
the WCGL.
Please note that the definition of "inaccessible markup"
refers to a definition in the WCGL, which doesn't exist.
Action Ian: Redefine inaccessible markup. Link from
instances of "inaccessible markup" to the definition.
KB: Propose changing "inaccessible markup" to
"inaccessible content".
2.7 Resolved:
Provide methods of checking and correcting inaccessible
content.
Checkpoints.
- 2.7.1: Remove "See the sections ..." and make it a note
for 2.7
- Remove "according to a user-configurable schedule" since
part of the definition of prompts and alerts.
/* Reminder: definitions of prompt and alert include
according to a configurable schedule */
- 2.7.2.
DD: Checking without reporting is pointless. The two
are bound together.
CMN: Proposes:
2.7.3 and 2.7.4 are subsumed by 2.7.1
DD: I'd like to see three checkpoints related to checking:
asynchronous, synchronous (on demand), on open/save.
CMN: Any scheduling feels like a technique to me. The
key is the alerting. The configuration guideline talks
about the details of scheduling.
GR: "Provide a mechanism to alert the author."
DD: When is user-configuration.
CMN: Checking is partially configurable: on open and on
save. Author also has the possibility of being alerted
during edited. Open and save should not be negotiable.
MD: Everything is negotiable. Forcing alerts is the
kind of thing that kills you in a review.
WL: Provide a hook so that the functionality of checking
can be used in non-UI circumstances, namely programmatic
control (in and out).
JT: You want to check at other moments than on save:
you want unobtrusive notification. Correction is
crucial to an authoring tool that promotes accessibility.
CMN: I'm not saying we don't do those things (they are
covered by the author having a schedule). The issue
is: is there a particular point when the document MUST
be checked. My suggestion is that if so, this be
a checkpoint.
DD: We discussed merging 2.7 and 2.8. Should we
revisit that possibility?
Also, we need to refer to two kinds of alert
(obtrusive, unobtrusive) from checkpoints.
KB: I don't like the idea that you MUST have
something even if the user wants to turn them off.
** For 2.8, we need a guideline that says that the
default configuration must promote accessibility.
It should not be easy to turn off accessibility checking,
but it should be possible.
JB: I am also uncomfortable with a phrase from
earlier: "it doesn't matter how much of a sales
problem it is". The author has to be able to
configure the tool to different levels. Not everyone
will be using tools in a compliant situation.
MD: Please note that a "checking" process may be
time-consuming. If applied on every open or save,
may be too time-consuming.
2.7.1 Resolved:
Check for accessibility and validity problems and alert
the author of them on a configurable schedule.
Issue: Should 2.8 and 2.7 be merged?
KB: I think there are other configuration besides
checking/alerting.
Resolved: Don't merge guidelines 2.7 and 2.8
DD: Two kinds of checking: valid HTML and accessible HTML.
CMN: These are techniques of checkpoints discussed
elsewhere. We can point to existing tools.
- 2.7.2.
IJ: Proposed changing "know the details of the markup"
to something based on the tool, not the author.
Proposed: Two checkpoints:
a) Assist correction
b) Don't require direct markup editing.
CMN: Doesn't a include b?
JT: We want assistance to resemble the authoring tool
mode: when markup edited directly, assist that way.
When manipulated through an interface, assist that way.
KB: Barrier to authors if we require them to know
all the accessibility features of HTML, CSS, etc. They
don't want to know the inner workings.
CMN: I'd like "a" only. Implementation of "b"
allows product differentiation. These are therefore
techniques, not checkpoint-level issues.
JR: I kind of agree. We can't assume that just
because most of the tool is WYSIWYG, the access
functionalities will be, too.
JT: Perhaps "a" only with a link to the checkpoint/guideline
about "integrate naturally".
KB: I want more than "integrate naturally". I don't want
to know the details. It's so important, it needs to be
a checkpoint.
GR: The point is well-taken, but I think it should be
a technique.
2.7.2 Resolved: (one checkpoint).
Assist authors in correcting accessibility
and validity problems in a way consistent
with the authoring interface.
- 2.7.3
IJ: Add "on a configurable schedule". Otherwise MS Bob
will be telling me "Way to go!"
KB: I don't love this checkpoint. I think it's
condescending. This would be a good technique for teaching
people, but should not be the authoring tool's role
to pat me on the back.
WL: The point is not to congratulate, but provide a status
report.
CMN: I do use software that tells me how far I've gone.
IJ: What's the measure of your progress?
Tool developers don't like to do look-aheads since costly
to calculate (e.g., after edits). Are there status
reports of spell-checking?
JR: There are binary ones in Word: no errors/some errors.
2.7.3 Resolved:
Provide summary information of document accessibility on
a configurable schedule.
/* 12:30 - 13:30 Lunch */
/* Bruce Roberts (Lotus) joins the meeting */
/* Judy Brewer, Mark Day, B.K. leave */
Guideline 2.8: "Allow authors to configure accessibility mechanisms"
WL: Should this guideline appear earlier in the document?
DD: I don't think the order will matter that much since
few guidelines in the end.
Also: Refer to earlier checkpoints that refer to
configuration (e.g., of help files).
Checkpoints:
- 2.8.1
Resolved: Delete "for a given set of options".
Also link "alert" to definitinon of alerts.
DD: What about when printed?
- 2.8.2
Resolved: Delete the parenthetical expression.
2.8.3 Resolved: Delete
Proposed CMN:
The default configuration should promote accessibility.
Resolved new checkpoint: [priority 1]
Include alerts for (WCGL) priority 1 checkpoints
in the default configuration.
CMN:
Don't restrict what can be done for configuration. There
are more pieces to configuration than just accessibility.
KB: Browser should be configured out of the box to
promote accessibility. Authors shouldn't have to
change settings.
BR: Wording of new checkpoint fine to me.
Proposed checkpoint:
Fundmental operations such as saving, closing, and pasting
should not be canceled or postponed due to he existence of
accessibility problems.
JT: Judy felt we should keep this.
JR: Guideline 2.8 (being at the end of Section 2) is
saying "We're not crazy; we don't want to make life
for users or developers difficult."
DD: Move to intro text.
CMN: If it's necessary for accessibility, make it a
checkpoint.
DD: What is the risk if you don't have this checkpoint?
Who won't do it?
KB: This is not a checkpoint for accessibility. Move
to intro of section 2. This is an instruction to
the developer. This checkpoint doesn't increase or
decrease product or markup accessibility.
GR: I agree: common sense, not a checkpoint. Belongs in
abstract, or 2. intro, or 2.8 intro.
Resolved:
a) Put in abstract
b) Put in section 2 intro text.
Resolved new checkpoint:
Select accessible options in the
default configuration of author preferences.
CMN: Propose moving 2.8 to 2.4 (and 2.5 combined).
This would even make the document more readable.
Does the look and feel include the default? Putting
them in the same place makes it obvious they do.
Resolved: Delete 2.8.
Move 2.8.1/2 -> 2.7
Move new checkpoint -> 2.5
Move 2.8 intro text to 2.7
/* Some editing done on section 2.7 */
Resolved 2.7 Checkpoints:
- Check for an alert the author accessibility and validity
problems.
- Allow authors to control both the nature an timing of
accessibility alerts
- Assist authors in correcting accessibility
and validity problems in a way consistent
with the authoring interface.
- Provide summary information of document accessibility on
a configurable schedule.
- Allow authors to choose different alert levels based on
the priority of authoring accessibility recommendations.
- Include alerts for WCGL Priority 1 checkpoints in the
default configuration.
Guideline 2.9
Resolved 2.9: Promote accessibility in help and documentation.
Intro: "The issues surrounding accessibility are often
unknown to Web authors. Help and documentation should
explain accessibility problems and examples of solutions."
Resolved 2.9.1: delete
- 2.9.2
KB: 2.9.2 sounds like it could be a technique of
a more general checkpoint along the lines
of "Provide help for accessibility-related issues."
2.9.4 Too touchy-feely.
BR: In our product, the author is divorced from the document
language. They access the features through the user interface.
Don't talk about "document language" since too techy.
Summary of main checkpoints for this section (after
which we'll choose checkpoints):
Resolved checkpoints (except for exact wording):
- Integrate applicable accessibility features
throughout help and documentation.
- Document accessible authoring practices
supported by the authoring tool.
[This is a slice of the documentation.]
- All help examples must promote accessibility
practices.
- Provide rationale (e.g., benefits to
other groups, mobile access, site management,
download times, etc.) for accessibility features.
Resolved: Move following checkpoints to techniques:
2.9.2 - 2.9.8
/* Break 15:30 - 16:00 */
Resolved: For checkpoints that don't have established
priorities, put "Priority X".
/* Review of discussion about Chuck's concerns */
- Priorities won't be listed in the document
unless the WG has reached consensus.
- The priorities will be negotiated after
(in general) the checkpoints are enumerated.
- The WG has done work to name problems and
find solutions to them. The WG doesn't have
a clear requirements document, however.
JB: It would be a useful test periodically to
elucidate the requirements. If the document
can't stand up to such scrutiny, there
is a problem.
DD: To me, the requirements are close to the guidelines.
JB: To me, the requirement is the unmet need. They
enumerate why things go wrong.
JB: Essential problem is that people put inaccessible
documents on the Web. Break this down into:
a) They are unaware.
b) The tool removes accessible features
c) The tool makes it difficult to get to accessible
authoring practices.
...
These are met by the basic strategies of this document:
alerts, prompts, configuration, etc.
JT: We have requirement lists in archives and older
documents.
JB: Then it would be good to isolate and name
(and verify it).
ACTION Jutta: Dig them up and ask questions about
them on the list.
/* Conference call time */
Constraints:
- US Pacific, US East Coast, Western Europe.
- 1.5 hours bi-weekly
Sylvain: Any time but Wednesday
Proposals: Every other Monday, 15:30 - 17:00 ET.
Every other Wednesday, 15:30 - 17:00 ET.
IJ: Wednesday 16 - 17:30 better for me.
Next teleconf: 8 March 15:30 - 17:00 ET.
JB: Possible conflict with PAGL WG on 22 March.
/* Section 3 */
Note earlier resolution: We will put intro text here that
summarizes (tersely) both the software and user agent
accessibility guidelines.
/* Jutta reads from 8 Feb 1999 email entitled
"Regarding Accessibility of Authoring Tools".
Considered a kind of list of requirements
for section 3.
*/
3.1 Resolved: Ensure independence of authoring and
publishing environments
/* Editor: Need to rewrite intro text to 3.1 */
One objection to 3.1 guideline wording: you can't
force an authoring tool also to be a browser. Also,
the intention isn't that you need to provide
a WYSIWYG view.
Resolved:
- We aren't talking about multiple user interfaces here.
- Delete 3.1.1
- Fix wording 3.1.2: Ensure that styles used
while authoring (e.g., large fonts)
are independent of those in the published
document.
(New checkpoints follow)
DD Proposed: Provide a structural view of the document.
For example, you insert a frame but don't want to
see the rendered frame - you want to know that a frame
is being used.
CMN: You want to provide information about the structure
of one or more documents (hinting at site map). You also
want to provide information about included objects.
DD: I distinguish multimedia (with descriptions) and
structural markup.
JT: Note that these checkpoints help satisfy the
navigation requirement in an authoring environment.
GR: Needs to be author-configurable which information
about document parts is available. Want to identify
elements as you go.
DD: Techniques include:
For images, file name.
For tables, ...
DD: This is a textual description (voice, braille, screen
reader).
Resolved: Allow the author to display a textual equivalent
of content while editing.
DD: (Note that textual equivalent
includes more than a longdesc or alt (e.g., can included
file name).
GR: Does 3.2.2 or some variation belong in guideline 3.1?
JR: site map is used twice. Once for producing content. Once
for working in the authoring environment
JT: therefore we need to rename the guidelines. There are,
in 3.2, pieces which will never appear in the published content.
DD: it is one feature of interface that is common, often
implemented by file management.
JT: one of the most popular wasa hyperbolic view which was
completely inaccessible.
DD: proposed to flatten the structure of this section for
the moment.
CMN: help / documentation must be accessible.
JT: it is in UA GL
JB must be here or it is ignored
GR must be reiterated
JB referred from the intro?
JT yes
JB OK
/* 17:30 Meeting Closed */
Received on Wednesday, 3 March 1999 09:58:09 UTC