WAI Authoring Tool Guidelines Working Group
Chair: Jutta treviranus, <jutta.treviranus@utoronto.ca>
Date: Wednesday 21 July 1999
Time: 3.30pm - 5:00pm Boston time (1930Z - 2100Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
The latest working group draft is http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990720.
Note that in most cases there is a thread of discussion following the message which has been referred to here.
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
Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile