W3C Web Accessibility Initiative

WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 21 July 1999

Details

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


Agenda

Review of Latest Draft

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.


Attendance

Regrets:


Action Items and Resolutions


Minutes

Techniques reviews:

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


Copyright  ©  1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.


Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile