Education and Outreach Working Group Teleconference
24 May 2013


WCAG Techniques Communications:

Three issues from WCAG Techniques Communications were discussed:

Easy Checks

The main discussion surrounded the usefulness of the images, the format, size and the frequency. There were pros and cons for having images. Whilst they are useful, the conclusion was that careful usage in a more strategic manner was advisable. Attention should be paid to the size and also to the presentation aspect leaving room for additional white space to alleviate the feeling of a crowded page.

Action items for next week:


  1. WCAG Techniques Communications - discuss open issues marked with [EOWG discuss] and highlighted yellow in WCAG Techniques issues wiki page
  2. Easy Checks - discuss new comments in Easy Checks wiki page, particularly things marked "EOWG". Discuss images. Edited sections:
  3. Reminder: Update your Availability for Upcoming EOWG Teleconferences


Andrew AnnaBell Denis Howard (last part) Shawn Suzzette Sylvie Vicki Wayne
Sharron, Helle, Liam


<shawn> http://www.w3.org/WAI/EO/wiki/Easy_Checks#Keyboard_access.2C_content_order.2C_visual_focus

WCAG Techniques Communications. (wiki http://www.w3.org/WAI/EO/wiki/WCAG_2_FAQ_Notes#Techniques )

<shawn> http://www.w3.org/WAI/EO/Drafts/WCAGtechniques#failures

Andrew: Reads the Failure case

Shawn: Suggested changes in wording

Andrew: Considered for deletion

Denis: authors know what to do rather than what not to do.

<Sylvie> Identify common accessibility barriers

Collectively: Failures document common (mistakes, error) for authors to avoid; Failures create barriers, Failures identify common accessibility barriers

<Andrew> Failures document some common accessibility barriers

Andrew: Failures document some accessibility barriers

<Sylvie> +1 to Andrew's suggestion

<Vicki> +1

Andrew: Something like failure is about the doucment rather than the indivudual techniques

AnnaBelle: Failures break accessibility … use a verb

<dboudreau> Failures identify some common accessibility barriers that are considered violations of Success Criterion x.x.x by the WCAG Working Group?

<Andrew> Failures are barriers to accessibility

Andrew, Denis: Failures are barriers to accessibility...

<Sylvie> Failures are barriers to accessibility that have been identified by the WCAG working group

<dboudreau> Failures are common accessibility barriers that are considered violations of Success Criterion x.x.x.

AnnaBelle: Are the common barriers?… Are they common?

<Andrew> Failures are documented barriers to accessibility

<dboudreau> +1 to Andrew

<Vicki> Prefer "Failures are barriers to accessibility". Simple and clear.

Andrew: Failures are documented barriers to accessibility

<Andrew> Failures are documented barriers to meeting WCAG 2.0 (more specific?)

Shawn: Failures are for authors to avoid, evaluators to check

evaluators to flag or find

Denis: This is meant to replace the existing pqge, are we trying to be terse

<dboudreau> Authors to know what to avoid, Evaluators to check that content does not violate a specific success criterion?

<Andrew> failures are useful for 1) authors to know what techniques to avoid 2) evaluators to know what comprises clear SC failures

Denis: See commnet

<shawn> http://www.w3.org/WAI/EO/Drafts/WCAGtechniques#intro

<shawn> "Techniques for WCAG 2.0 is not intended to be used as a stand-alone document. ... "

Andrew: We do need to tell people what to read, People just jump in.

<Vicki> I think we need it, too.

Denis: Just jumped into the techniques. Without guidence others would do it.

<Vicki> +1

Shawn: Should we cut down the link?

Group: Lots of agreement

Denis: These are just some examples, you could come up with others...

Shawn: Keep in one place… in Understanding

Andrew: People are just going to the document.

Shawn: It is important" that the concept that, techniques are just examples, others are possible", does not get lost

Andrew: Link what a programmer does, not a verb...

Denis: Move from there, point to there...

Shawn: If "link" as a verb use "follow link from...

Vicki: Link as verb is common but "follow link from"

AnnaBell: Cut "a customizablie quick reference"

Shawn: "Quick reference" has long history

<shawn> http://www.w3.org/WAI/EO/Drafts/WCAGtechniques#other-techs

Shawn: we've italicized terms not document names.

<shawn> The last bit is trying to address both developers and evaluators. It's a more succinct way of saying to authors that your web content doesn't have to follow W3C's techniques, AND saying to evaluators that when you're checking web content, it's OK if it doesn't use W3C's techniques. Would it help to say:

<shawn> "Web content does not have to follow W3C's published techniques." or

<shawn> "Web content does not have to implement W3C's published techniques."?

<shawn> or can we keep the simpler word "use"?

<shawn> or is there another simple way to say it? {Shawn}

To authors content does not have to use w3 techniques

<dboudreau> In addition to the techniques published in the W3C's Techniques for WCAG 2.0 document, there can be other ways to meet WCAG success criteria. The W3C's published techniques are just some of the ways through which SC compliance can be achieved.

Shawn: Authors do not have to use w3 Techniques

<Andrew> +1 to Denis

Denis: see comment, Telling them that they "don't have to use them" lessens the techniques that have been documented.

Andrew: Remainder flows from Denis

<Andrew> can we sugegst they document their 'proof'

<Andrew> Wayne: developers have been known to overstate their conformance - we shouldn't give them too much room to move on this

<Andrew> Wayne: many are using WAI-ARIAtechniques instead of traditional techniques, and these are not available to all

<shawn> If techniques are used other than those listed by the Working Group, then some other method for establishing the technique's ability to meet the success criteria would be needed.

<shawn> (from current How to Meet / Quick Ref

Andrew: Can they give a method to prove their techniques

<Andrew> +1 to saying more about 'cautions'

<dboudreau> In addition to the techniques published in the W3C's Techniques for WCAG 2.0 document, there can be other ways to meet WCAG success criteria. The W3C's published techniques are just some of the ways through which SC compliance can be achieved.

Denis: People will come up with their own ideas, that fail. We we open the door to create techniques, then it is the evaluators task to identify possible failutes.

There can be other ways to meet the success criteria instead of "there are"

Easy Checks - keyboard comments

<Andrew> s/"There can be other ways to meet the success criteria / "There can be other ways to meet the success criteria" /

<shawn> http://www.w3.org/WAI/EO/wiki/Easy_Checks#Keyboard_access.2C_content_order.2C_visual_focus

<shawn> "Keyboard access, labels, content order, visual focus" ->"Keyboard access, content order, visual focus"

<Sylvie> I agree to simplify.

Shawn: Can we call this Keyboare and Visual Focus.

<Andrew> http://www.w3.org/WAI/EO/Drafts/eval/checks#interaction

<Andrew> +1

<Vicki> +1

Wayne +1

<dboudreau> +1

<AnnaBelle> +1

<Suzette2> +!

<Suzette2> +1

<shawn> The "To learn more..." section has "Example: web page template that does not enable keyboard access from the WAI Before and After Demo (BAD)" I tried using the BAD pages to test keyboard access but they didn't seem particularly useful. afaik, the tab focus disappears after the QUICKMENU drop down. So I'm not sure it's worth listing BAD here at all. Shall we delete it? {Shawn}

Andrew: Cannot get to the QICKMENU

Shawn: Confirms
... Do we want to demonstrate good?

Bad fails to fail

<Vicki> Firefox 16 also get stuck

Denis: Firefox gets stuck at Quickmenu

<AnnaBelle> I do in Chrome too

<dboudreau> confirms getting stuck on quick menu with FF20

<shawn> http://www.w3.org/WAI/EO/Drafts/eval/checks#contrast

Shawn: Droup the example

<shawn> Contrast Ratio ("color contrast")

<Vicki> good try denis

<Suzette2> +1

<Vicki> fine for me

Shawn: Do expand all to see the updated images: ones that illustrated the point and ones that show menu options.

<shawn> *Questions*: How is the current use of images for illustrations throughout the draft? Too much? Not enough? Mostly helpful? Too cluttering? Feel free to comment in general, and on specific images.

<Vicki> yay

Denis: Some in the title section are confusing

Andrew: Cautions: We know what to look for, to newbies the pictures may help.

Shawn: One general point: be aware that some people may need images, we get criticized for being text heavy, we edited to simplify -greyed out irrelevent comments
... Contrasd Ration:

Found genrally useful, but color blind friends are confused.

Zoom is useful; Images can be edited

Denis: Cut out bottom

Would like side by side.

annabelle & andrew also

Suzzette: agrees with others, need to cut some

Shawnn: First images shows how : to check title in firefox and other browsers

Denis: Clutter

AnnaBelle: Agree with Denis

Shawn: It was hard to find, but no picture

Denis: Instructins good but no need for picture

Shawn: see to Chedk Alt Text
... Jump to color contrast: To check contrast with IE WAT
... keep or clutter

Suzzette: Maybe the spacing needs to be adjusted

AnnaBelle: Less necessary than title, because skill level is higher for IE WAT

Denis: Not sure ...

AnnaBelle: Need to be strategic, not everywhere

<Andrew> Wayne: is everyone verbally oriented? or visually oriented?

<Andrew> I'm visually oriented

Shawn: Devils advocate: People may not be advanced users
... I'm gong to use tool bar, my office only has IE, … what about this use case
... Other perspective… user is visual, … confusing path, With visual can use middle, thiird of three

AnnaBelle: Want to use images most effectively… Need in title, maybe not in other, if we have a good image in IE WAT and not Title will be frustrated.

Andrew: are they clutter? You only see the images as expanded it for alll

Denis: Spread sheet of criteria with test, Have never had complaint, Shared extensively, Peiple do figure it out.

Need inages for globally,

Denis: Did have wide user choice

Wayne: like pictures in general, couldn't see them.

Andrew could you write you thought

<dboudreau> That being said, I recognize I'm kind of a minimalist

Suzzett: Find it useful. Luke warm about menus. Show them what to achieve

<Andrew> likes to see the pictures to illustrate the use (specially for new and/or visual users) - as a minimum, we should show the tool when we introduce them as an option for testing

Vickie: Finds it really useful. Likes a small image, not too many, maybe menu change, need a good balsnce. Like in the instruction.

Shawn: need to turn on and off

Denis: Current layout makes it cluttered.

Suzzette: Presentations has a lot to do with it.

AnneBelle: placement is important

Howard: Mostly word smithing, but good

<Vicki> i'll look it over next week.

<shawn> Question: status of multimedia sectin review?

<dboudreau> only skimmed through it for now

<Andrew> +1 - not so frantic next week

<AnnaBelle> look over next week too

<Howard> I thought it needed work. I'll look at it again.

For next week look at multimedia and keyboard

Shawn: there are some missing @@, keyboared commands, Next steps needs work

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013/05/24 23:33:08 $