Here are the minutes of the July 21st meeting

Here are the minutes of the meeting. The action items are at top. As there
were several minute takers there is greater brevity during some of the
meeting.

Present:
William Loughborough
Jan Richards
Dick Brown
Gregory Rosmaita
Kynn Bartlett
Jutta Treviranus

Regrets:
Charles M.
Ian Jacobs
Wendy Chisholm
James Allan

Action Items:

Proposal: to use Jan's new wording for techniques of 4.4 (pointers to
transcript files can be stored rather than full transcripts)
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0025.html
Agreed

Proposal: to use Jan's new wording for checkpoint of 4.3 (explicitly
stating that pre-written alt. content should be used as default field
entry not automatic insertion)
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0025.html
Agreed

Action Item: Jutta to figure out why the numbering of the checkpoints for
Guideline 4 have changed.

Proposed: Change wording of checkpoint 5.1 to "When presenting the author
with a choice of implementation strategies, ensure that the highest
-priority accessible authoring practices are among the most obvious and
easily initiated by the author."
Agreed

Proposed: Adopt Jan's edits to techniques with clarification regarding
accessible content vs. accessible technique. Remove two techniques as
proposed by Jan in:
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0008.html
Agreed

Action Item: Gregory to find new home for 5.2 technique regarding NoFrames

Minutes:
For discussion of guideline 4 see Action items. (minutes taken by J.R.)

Discussion of techniques for guideline 5: (minutes taken by J.T.)
JR: Reviewed
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0008.html
Replace example with: " For example, when the user has
selected text to format, the use of CSS for colour should be emphasized
rather than FONT."
db: should this be in there, are we dictating how the interface should be
written
wl: can be in there
jr: niaive user doesn't care how turns blue, we care that way turned blue
is accessible, when two ways of doing things
db: what if not using CSS
jr: then not applicable
db: example not applicable
db: shouldn't get that far down, telling them what to present to user
wl: wait, want to make sure that what gets put into markup is not
deprecated proprietory markup
jr: when you click a centre button in a toolbar, the niaive user just wants
it centred, the interface determines how
gr: maybe should have technique for toolbar
jr: applicable not just to toolbars, just visual corrollary to don't
generate inaccessible markup
db: still feel the two checkpoints are inconsistant, a feature is not
naturally integrated if highlighted
jr: no are consistant, can be both highest priority and integrated
db: you're saying don't give the user the choice
jr: Microsoft doesn't give them a choice now, we are just saying make the
most accessible one the default
db: we are not saying have the most accessible one be the default
gr: they are complimentary,
db: do we need both, why do we need 5.2
gr: yes
jt: there is still user freedom, all choices will be provided but the
interface will guide you toward an accessible alternative
db: examples don't support 5.1
jt: example should support choice
wl: problem: there is a conflict when alphabatized
gr: can have the accessible one highlighted
db: not realistic
jt: can you give further examples of problems you are having, when would
the two conflict
db: can I get developers to do this, don't want me in there telling them
how to design the interface. Telling them to generate accessible markup is
one thing but telling them how to design the interface is another.
jt: user does have control of accessibility of content
db: getting too far in dictating interface design
jt: possibly offending word is highlight
db: asking them to analyze which alternative is more accessible, that is
too difficult for the developer
jt: we don't want to impose a new hierarchy where there isn't one, if there
is a hierarchy then make sure the most accessible is at the top
db: not well thought out, need examples
wl: are probably no examples
db: already say use accessible practices, why do we need this
kb: 3 addresses that practice be available, this is saying design needs to
favour accessibility, if you are going to have 2 options, should not be an
explicit order that downgrades accessible option
db: 5.2 goes far enough, 5.1 goes too far, not realistic
kb: put "among the most visible and easily intitiated by the author"
db: we still need examples
jr: 5.1 is priority 2 if clashes with 5.2 then 5.2 takes precedence
wl: among solves it
jt: not asking for new hierarchy
wl: real point get away from ghettoization of advanced features
gr: would flip flop 5.1 and 5.2
 add phrase when presenting the author with a choice of implementation
strategies
jt: any objections
db: still have problems what do we mean
jr: alt text example, must go to advanced to add alt-text
db: what we are talking about in 3 produce accescible content and here we
say present accessible choice to the user. If someone follows 5.2 they may
not be in compliance with 5.1.
jt: can you think of an example where they would not be in compliance
db: i need to take it back to the people and get their feedback
g and w: we need their feedback

jt:resolved will add wording to 5.1, dick will get feedback
Jan do you want to go through others
jr: minor edits see
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0008.html
jt. no objections to edits to Ensure that accesible authoring practices
gr: edit needed
db: in this one are we talking about an advanced?
jr: yes, don't put it after obscure items
gr: beautifully written technique
db: this last edit, the way it exists in the first place are we implying
that it is hard to get at the settings and we want to make it easy, no
software designer sets out to make things difficult to do, this sounds
condescending
jt: this is just a technique, not prescriptive, if already doing it this
confirms it
db: seems like fluff, obviously MS does not want products to take too many
steps
jt: next revision: ..do not
gr: well said
jr: see factory settings
db: accessible content or accessible interface?
jr: accessible content, should be edited
jr: next should lose techniques
jt: resolve add new techniques, adopt rewording with clarification
regarding accessible content and lose last two techniques
gr: don't think we should lose noframes checkpoint
jr: isn't this in content guidelines
wl: can't have too many techniques
jr: how does this address the checkpoint
db: good point but out of context
jt: any candidate for where else
gr: guideline 3
db: are we getting into this level of detail in techniques
gr: I would put it into 4.2 or 4.1, I just don't want to lose it, frames
are the #1 problem when reconstructing
db: are we then saying that we are picking the examples that are most important
jt: until any further objections
wl: objections to grammar of 6 change to "checking for"
kb: add a definition of documentation
change to documentation wherever we say help text or
jt: do we agree with kynn's proposal - defer to next week
gr: add len kasday's issue to next weeks agenda
jt: meeting adjourned