See also: IRC log
<achuter> zakim mute me
<shawn> scribe: Sharron
Shawn: Two next calls, Alan will be available for the entire meeting, so let's try to get through all of his documents on those two calls. For now, pick up the discussion from the BP comparison document at Color Contrast
William: Are we working on the language of thiese?
Shawn: Focus on central ideas and language
issues should be sent to Alan directly and cc editor's list
... Alan, the document looks great, the CSS you used has made it easier to
read and follow.
<yeliz> We can't here Alan
<yeliz> hear Alan
Shawn: so ...color contrast, any comments?
Doyle: what does BP mean?
William: Best Practices
Shawn: still can not hear Alan, can you use IRC for comments?
<achuter> Yeliz did the CSS work
<achuter> I think that the "How does it help" section is too long
Shawn: Color Contrast OK, next is Control Labeling
William: I would like an example to demonstrate a form control
Shawn: You should get that information from the Guidelines not from this comparison document.
William: It makes it hard to follow this, right now
<achuter> Would like people to go back to color_contrast and look at the link under "Does help meet any WCAG 2.0 success criteria? Possibly."
Andrew: Text entry box, check box, etc
<achuter> "Possibly" is a link to a definition.
<achuter> Is it clear? Probably not as nobody noticed it.
Shawn: Going back to color contrast, does it
help meet any WCAG 2.0 success criteria?
... Does it help to have a link to the defintition of the word itself
"possibly"
Yeliz: Yes it does help to have that link
Andrew: Should we make it more definitive?
<achuter> Alan to look at repeated word "criteria" in "Using the more precise criteria given in the success criteria"
Shawn: Since the BP document does not use that
term, may not be helpful
... Any thoughts on that?
<achuter> Don't see what more we can do.
Shawn: a couple of votes to link the words "possibly" and "probably", any votes against?
Andrew: At first glance, you think you will get a definition of why it is possible, but after you read one, will know what to expect on the next one.
Shawn: Now to control labeling. Anything,
commments on that section?
... being none, on to Control Position. Any comments?
... no WCAG 2 criteria on that one?
William: Do people know what properly is?
Yeliz: Can we also talk about people who use modified screens, other than screenreader users?
Shawn: That's why I am surprised there is no correlation to WCAG.
<achuter> Referring to what William says, maybe say what the position is
<achuter> It's explained in WCAG 1.0 but not elsewhere
<achuter> Just a link.
Shawn: May not be fully explained elsewhere because it is not simple. Less inclined to want to link to 1.0
<achuter> Alan remember to split up the tip into two.
<andrew> Andrew: add discussion of cognitive impaired also benefiting from layout
<scribe> ACTION: Alan for control position, consider adding issues for people with low vision especially magnifiers, and consider if it is appropriate to make actual uggestions on positioning. Double check realtion to WCAG 2.0 [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action01]
Shawn: Alan, perhaps we can flag to reviewers
that we want them to focus particularly on this one for WCAG 2.0
relationship
... anything else on control postion?
<achuter> This means restrict the characters oen can type
Shawn: then to default input mode, comments?
<achuter> Like numeric-only
Shawn: So let's jump down to the provide
defaults link if you want to see the answer there. Alan, how often do you
link to another rather than repeating the answer?
... what does the group think, is it better to jump to the similar answer or
to repeat it?
Yeliz: repeat it
Doyle: since it is short enough, repeat it and reference the other
<scribe> ACTION: Alan for default input mode, instead of linking elsewhere, just repeat it here. [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action02]
William: are we sure no is the answer?
Shawn: pretty sure, yeh
<achuter> Maybe WCAG WG didn't know about it.
William: I am thinking about cognitive issues that there may be a WCAG guidleline that applies
<achuter> It's an attribnute
Shawn: There is something tht says provide instruction, Alan would it apply?
<achuter> There's not much support and only in XHTML Basic I think.
Shawn: On to section on Error Messages...comments?
<achuter> http://www.w3.org/TR/WCAG20/#minimize-error
<achuter> Maybe there is one.
Shawn: I thought there were WCAG 2 relevant to this?
Andrew: 3.3.3 may be related
<achuter> I think this is more about server errors, like non-existent pages or backend failures
<scribe> ACTION: Alan on error messages, recheck WCAG 2, including 3.3.3 [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action03]
Yeliz: May be differently focused. In mobile, may be focused on improving navigation through error messages.
Shawn: OK, will check.
... next section is fonts and font related sytling. Comments?
Yeliz: Not sure about the term "non-visual users"
<achuter> This (FONTS) is wrong. Should be "if information is conveyed by CSS"
Shawn: Is blind user better?
... Generically, nonvisual users vs users who are blind
William: or blind users
Andrew: what about situational blindness?
Doyle: aren't we talking about people who navigate in other ways? I think it would be good to include the use case.
Lisa: Terrible phrase, but non-sight dependent, meaning sight is not primary means of deriving information.
Doyle: like people who are line coding, not using a GUI, not using visual capacity.
<achuter> Can't we just say "users who don't see the font changes"?
William: It's not just wording, it is a matter of using fonts to convey information. Doyle is right that it is people who are using the interface non visually.
<achuter> This (FONTS) is wrong. Should be "if information is conveyed by CSS"
<achuter> Or not even with CSS
Andrew: People with low vision who may use own style sheets could miss information
Shawn: Isn't it broader than CSS, just information conveyed visually?
<achuter> Some users can not perceive font styling. If information is conveyed using font effects these users may have difficulty understanding the meaning of content.
<scribe> ACTION: Alan FONTS - make it broader than using CSS. Something like If visual font effects convey information, that information is not avaialble to non visual users and people who change fonts. For example with their own CSS that [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action04]
William: If Alan gets back to the BP world, do not rely on is not imperative enough, may be neither here not there.
Shawn: Next is image maps. OK?
<achuter> They are at proposed rec, so won't change the document
Shawn: Alan I hope you will submit these
comments to the BPWC, would you leave this comment in here, or is it only for
us?
... can you have non substantive changes? Alan do you want to double
check?
<achuter> I think that if they start changing one thing they will have to make lots of changes
<achuter> It could stay as a comment, but maybe not hightlighted
Yeliz: But if it remains, it needs greater explanation, might be better to add detail.
Shawn: Any objections?
<scribe> ACTION: Alan - image map, explain comment and unhighlight it. [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action05]
<achuter> Put the definition of "no added benefit" in definitions section
Yeliz: When you click on the no added benefit link, it goes to a general discussion
<scribe> ACTION: Provide more specific information for no added benefit link within image map section [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action06]
Yeliz: There actually may be benefits to screenreader users.
Andrew: Problems with spatial relationships, like shape of country.
Shawn: How about if we ask Alan to rethink this one.
<scribe> ACTION: Alan rethink Image Map in light of these comments [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action07]
<achuter> Change to "do not apply (and therefore it is not necessary to...)"
Shawn: Does WCAG comment make sense here? I am re-reading it and not sure I am understanding
<scribe> ACTION: Alan Change to "do not apply (and therefore it is not necessary to...)" [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action08]
William: am I to understand that 1.1.1 does not apply to image maps?
Shawn: this one is related to device support only
William: what is purpose of sentence that begins, when image maps are not present
<achuter> Not present because the device is detected as not supporting them
<achuter> If it does support them, then you will use them.
<achuter> So for desktop graphical browsers they can be used.
Shawn: Maybe nature of this best practice makes it irrelevant to our purpose, it seems the only parallel may be to unsupportive AT and we don't have that as an issue. May not be relevant.
Andrew: What about something like 2.1.1 , may be worth rereading and seeing if it has correlation?
Yeliz: I think here, Alan is trying to say tht if someone follows the BP and does not use image maps, the following does not apply.
<achuter> You can know if the device supports them.
<achuter> Using device description repository
Shawn: but conceptually, if I am working on BP and I know a device supports image maps and I will use image maps. In that case, this does not relate to WCAG
<achuter> Yes, but in practice you may decide not to use them at all.
Shawn: so I can follow this BP allows you to do both presnt image maps or not, and it is not really relevant to compare it to WCAG
<achuter> To save work.
Andrew: bacause then you do not have to check the device.
<achuter> In practice I think people will avoid using them altoghether, so the SC probably won't apply
Shawn: Is this an important point or can we say no added benefit?
<scribe> ACTION: Alan image maps, consider if it may not be important to list any of this information here? Perhaps leave it out altogether. [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action09]
<scribe> ACTION: Move the Back to Best Practices link outside of the visual box. [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action10]
<achuter> Yeliz did the design
Shawn: But really really like the redesing of how things are grouped....thanks Alan and you are on for the whole meeting next time.
<shawn> take up next week at http://www.w3.org/TR/mobile-bp/#LINK_TARGET_ID
<andrew> http://www.w3.org/WAI/PF/aria-primer/#reasons
Shawn: Thanks Lisa for your good work, go to EO
Agenda, second document for our review
... Lisa, WAI ARIA and WCAG 2, is there any risk that people may think this
is a reason for adopting WCAG 2 period? Could we say, adopt ARIA 'with'
WCAG?
Lisa: umm....we could. Let's look
... yes, with will make more sense, I totally agree
<shawn> ACTION: lisa change "Reasons for Adopting WAI-ARIA and WCAG 2.0" to "Reasons for Adopting WAI-ARIA with WCAG 2.0" [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action11]
Shawn: have you had a chance to look at Alan's comments, I am debating if it is a stretch.
Lisa: Oh sorry, I meant I had looked at William's comments. I think they are good ideas about mainstreaming these ideas, that it is a general best practice. So will try to incorporate William's comments
Shawn: Andrew, were you going to get specifics
in support?
... what is timing on that?
Andrew: Can't remember exactly what the plan
was...
... will talk further wih Francois
Yeliz: If it will help, I can also bring it to the attention of MWBP group.
Lisa: Yes, please.
Shawn: Will look at ways to get specific examples of how it can help in MW arena?
William: Also makes significant difference , when I look at illustrations here, I think addition that it makes is a very good thing generally. Beyond accessibility, mobile web.
Lisa; I beleive that to be true, but we need examples. One example is that ARIA enables stuff scales better across devices, resolutions, browsers.
scribe: levels of connectivity.
William: Right on!
... what is "keyboard-like, desk-top widget?"
Lisa: Meant to be "desktop-like tree widget"
Willaim: Overall comment about bullets, content should be bullet-like, not narrative. Should be punch, not explanatory.
Lisa: Make bullets short and terse, and follow
with explanation text.
... could use definition list.
Shawn: Will have some people uncomfortable with using definition list if not definition
Lisa: will look at it
Shawn: Let's leave to editor's discretion
William: Overall doc is great.
<shawn> Alan's comments http://lists.w3.org/Archives/Public/w3c-wai-eo/2008JanMar/0129.html
Yeliz: First paragraph, wording may give wrong impression about usability and WCAG
Lisa; I understand what he means, but part of me wants to say that is a defensive posture. With WCAG 1.o you could make a doc that met criteria but was not usable.
Yeliz: Instead of talking about negative aspects of 1.0, could we not emphasize positive aspects of 2.0?
Lisa: The reason to make the distinction was so businesses would understand that there is pain that one wanted to move away from and encourage them to move to WCAG 2.0 and ARIA.
Shawn: Is there anyone who is trying to build accessible rich media documents who doesn't know the pain?
Lisa: Remember the audience, many are not even trying.
Shawn: remember that WCAG 1.0 is the only
standard at the current time, and is the standard of many countries. So there
is that reality that we must be sesntive to the fact that they must follow
WCAG 1.0 in terms of legality, policy ,etc. And there will be transition
time.
... So let's think about opening approach. Here are all the great things
about WCAG 2.0 and ARIA and later on, by the way, you can't get this from
1.0
Lisa: That makes sense, when re reading it after a few days, I hear the business voice about why we need to make the move. OK, I understand.
William: Beneath Reasons for Adopting, first
two sentences probably belong in 3.1.
... and so development reasons have to do with why you change from 1.0 to
WAI-ARIA with 2.0
Yeliz: I agree with that change. My real
concern is with the first sentence. It may send the wrong message.
... using WCAG 1.0 still provides benefits, even if 2.0 is better.
<shawn> aciont: Lisa change the approach of "3 Reasons for Adopting WAI-ARIA..." so the primary message is Wai-aria is great for these reasons. and secondarily the benefits over WCAG 1.0
<shawn> ACTION: Lisa change the approach of "3 Reasons for Adopting WAI-ARIA..." so the primary message is Wai-aria is great for these reasons. and secondarily the benefits over WCAG 1.0 [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action12]
Shawn: Back to Alan's comments...
Lisa: He says outdated methods that do not scale well is hard to understand...
Shawn: "scale" is a word people might not understand.
William: is there WCAG 1.0 with ARIA?
Lisa: No, if you read concluding paragraph you see that they must proceed in lockstep.
Shawn: You can use WAI ARIA if you use
progressive enhancement in the creation of Javascript.
... if they have JS enbaled they get it, if not, they don't.
... I think that is a key point, in terms of our messaging and in terms of
reality.
... WAI ARIA enables you to meet 2.0 better, but is not dependent on 2.0
Lisa; We don't want people to wait for 2.0 to be gold to use ARIA, no reason not to use ARIA now.
Andrew: Yes that sums it up
Shawn: We need to decouple the 1.0 / 2.0 issue.
Doyle: Why would we want to do that? If it is clear that 1.0 will work but you get greater benefit from 2.0?
Shawn: Don't think you get more benefit from 2.0...ARIA is exactly the same, they are not related.
William: We want you to use ARIA no matter what guidelines you are using.
Andrew: With 1.0, you must worry about degrading, with 2.0 you don't.
Lisa: My perception of reality is not changed, I now have more arguements. I do not want to decouple it, because we want them to a. move now and that b. adopting it now will smooth their ramp to 2.0
Shawn: Want to change the idea that ARIA is dependent on 2.0.
Lisa: That I agree with.
<shawn> ACTION: Lisa - change the approach so it doesn't seem that WAI-ARIA is dependent on WCAg 2.0 [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action13]
Lisa; These changes will make it stronger and clearer. Previously, if I was a non-techie business person, would I understand?
William: Parts seem to me to be developer reasons rather than business reasons.
Lisa; As an enginerrng project manager, I have to add an additional factor for cross browser efforts. But, yes it is both a business and a developer reason.
William: It should be reflected in both.
<scribe> ACTION: Look at business vs business and considering including in both [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action14]
Lisa: IE 8 support was so exciting because it was needed from business perspective.
Shawn: need to get implementation page going
<shawn> ACTION: shawn - look at adding to FAQ that all major browsers pledged to support it [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action15]
Shawn: any other response to Alan's comments. Lisa, anything you need from the group? For the group..any of Alan's comments that you don't agree with?
Lisa: No issues, some that I need to think about.
Shawn: Reasons for adopting WAI-ARIA, not WAI-ARIA with 2.0
<shawn> ACTION: Lisa "3 Reasons for Adopting WAI-ARIA and WCAG 2.0" > "3 Reasons for Adopting WAI-ARIA" [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action16]
Lisa: you want to nix the figure?
Shawn: no, just the title
Lisa; OK because the figure illustrates the migration to WCAG 2.0
<shawn> in the figures, take "WCAG 1.0" and "WCAG 2.0" out of titles. then they're something like "Without WAI-ARIA" and "With WAI-ARIA"
<shawn> ACTION: Lisa, in the figures, take "WCAG 1.0" and "WCAG 2.0" out of titles. then they're something like "Without WAI-ARIA" and "With WAI-ARIA" [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action17]
<scribe> ACTION: Lisa in the figures, take "WCAG 1.0" and "WCAG 2.0" out of titles. then they're something like "Without WAI-ARIA" and "With WAI-ARIA" [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action18]
Shawn: anything else on this section, anything else on the list comments?
Yeliz: there are two sections, business and developer. What about a section for users?
Lisa: User benefits are covered in overview. Target audience is business and developers.
Andrew: Should be reinformced within busienss reasons as benefits to customers
<scribe> ACTION: Lisa consider adding as a commetn and pointing to more detail. [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action19]
Shawn: Conceptually it would be useful and to bring that home that the real reason is because it is better for users.
<shawn> ACTION: Lisa, consider adding user benefits to section 3 - even if mostly just points to info elsewhere [recorded in http://www.w3.org/2008/03/07-eo-minutes.html#action20]
Lisa: for all users
Shawn: any closing comment? March 21 meeting is still open, though most of Europe will not join. So since we are behind on WAI-ARIA we will meet even as a small group.
Lisa: What about March 14?
Shawn: Yes we are meeting.
... goodbye, good travels, see you next week.
<yeliz> bye
Lisa: thanks for the good comments
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/XHTM/XHTML/ Succeeded: s/suer/user/ Succeeded: s/inormation/information/ Succeeded: s/change/comment/ Succeeded: s/special/spatial/ Found Scribe: Sharron Inferring ScribeNick: sharron Default Present: doyle, Loughborough, Shawn, achuter, yeliz, +1.512.305.aaaa, Sharron, andrew, Jack Present: doyle Loughborough Shawn achuter yeliz +1.512.305.aaaa Sharron andrew Jack Regrets: [get from mailing list] WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting Agenda: http://lists.w3.org/Archives/Public/w3c-wai-eo/2008JanMar/0121.html Got date from IRC log name: 07 Mar 2008 Guessing minutes URL: http://www.w3.org/2008/03/07-eo-minutes.html People with action items: - 2.0 adding adopting alan at benefits change consider for lisa look move provide reasons shawn user wai-aria wcag[End of scribe.perl diagnostic output]