Action Items

Shawn: We have been using the Tracker but many items go out of date and people forget to look at them. A suggestion was made to use the wiki for tracking instead.
... a minor problem is that they will not be auto-added via IRC so it would add a manual step. What would be easiest? Any preferences?

AnnaBelle: The wiki would be easier, I just don't get the tracker interface.

<Helle> me too

<shawn> http://www.w3.org/WAI/EO/wiki/Action_Items</ a>

<Denis> would prefer the wiki too

Paul: I am comfortable with the Tracker but for discussion it might work on the wiki.

Denis: Prefer the wiki

<Paul> Prefer tracker for to-dos, wiki for discussion

Suzette: find the Tracker confusing. I like the idea of long term items on the Tracker and can use the wikifor immediate items

<Andrew> happy either way - tracker sends email

Sylvie: I remember when you add to the Tracker through IRC, who will do the items on the wiki?

Shawn: Either each person can do it themselves or we can make it part of minute clean-up.

<Paul> to-dos in the sense that I have a task that must be completed by a specific date (sorry for not being clear, I haven't had coffee yet)

Sharron: Making it part of minute clean-up works

Shawn: We will need to change the designation. Action colon makes it a tracker item automatically. Editing on the fly is a possibility and can be added during the meeting.

Andrew: We need to think about the fact that Tracker sends an email and reminds you.

<Andrew> suggest using - "Action - " instead of "ACTION: "

Shawn: We will get in a habit of checking the Actions each week, maybe right at the start of each meeting

Easy Checks Public Comments

<shawn> http://www.w3.org/WAI/EO/wiki/Easy_Checks_Comments#Peter_2_July

<Howard_> agree with Andrew

<Howard_> agree with Andrew's comment on RTL on wiki

Denis: In reviewing these comments, I tend to agree with yours Shawn about the probablity of adding confusion.

Suzette: It was an interesting comment to make, but I feel that it is covered by the general remark that it is referring to left to right.
... +1 to Andrew's comment

Shawn: Shall we put a note to translators to say "Feel free to adapt text and image to match your language"
... in this section? at the bottom?

<Howard_> at bottom

<Denis> +1 to Andrew

Andrew: At the bottom since it would apply to any of the images

<hbj> +1

Suzette: Yes

Shawn: Next comment

<shawn> http://www.w3.org/WAI/EO/wiki/Easy_Checks_Comments#Neil_Soiffer_8_July

Shawn: from Neil, 8 July

<Paul> Suzette spoke for me about putting it in the tutorial :-)

Suzette: This was a good solution from my perspective.

<shawn> http://www.w3.org/WAI/EO/wiki/Easy_Checks_Comments#.5BOPEN.5D_Comment_4_VC

Shawn: Next comment was Open comment 4VC related to keyboard access
... the focus not stopping - suggestion is to add (This is best practice, though not a requirement.) consistant with other cases in which we did this.

<Howard_> like parens

Denis: Isn't it a keyboard trap?

Andrew: Not if you can move backward out of it.

Denis: Would you not have to provide a way to bypass the block by getting to the bottom? It breaks something in the keyboard operation.

Shawn: Shall we check with WCAG for that?

<Paul> agree we should check with WCAG

Action added for Shawn to the wiki action page

Bim: If they must go backward to get to the home page, it does break keyboard action.

<Paul> could the end of page "trap" be a function of the UA?

Shawn: Bim and Denis would you add your comments to the wiki what you think are the justifications for having this be a violation of WCAG rather than a best practice?
... how often does this occur?

Denis: Never

All: Not seen it

Shawn: Then if it is such a rare occurance does it actually belong in the EasyChecks at all?
... if it is highly unusual, does it belong in an easy check?
... proposal is to delete this item entirely...any objections?

<shawn> http://www.w3.org/WAI/EO/wiki/Easy_Checks_Comments#.5BOPEN.5D_Comment_3_VC

Shawn: ...offered another way to check the page title. Current resolution is to keep it with the simple way we have. Although Howard and Sylvie added some additional ways to check. So do we want to hold it with the simple way originally suggested or add other ways to check for page titles
... now we say look at the structure. So a reason to keep it is that it is very direct and simple way to check.

<Howard_> would keep as is - keep it simple

Andrew: I support keeping it as simple as possible.

<shawn> http://www.w3.org/WAI/EO/wiki/Easy_Checks_Comments#.5BOPEN.5D_Comment_2_VC

Shawn: Next is Open Comment 2VC
... this one is related to visual focus. We state that the visual focus should be equivalent whether it happens with keyboard or mouse.
... Reviewing WCAG SCs, what are people thinking?

Denis: There is nothing that says it has to be the same. It says that there must be visible focus but not that it be the same.
... I could not find anything that said it was necessary to be the same.

<Andrew> g90 - To do this, make sure that all event handlers triggered by non-keyboard UI events are also associated with a keyboard-based event, or provide redundant keyboard-based mechanisms to accomplish the functionality provided by other device-specific functions.

Bim: Visual focus has its own SC, the function is a separate consideration.

Andrew: Very literally to say it should be the same may not be part of the focus question, but it could be a question of functionality if there is an event that is triggered.

<Denis> my point is that if there's a functionality or feature provided with the mouse, then it needs to be provided on keyboard too - without a doubt. But it doesn't need to be the exact same behaviour or experience.

Shawn: So is the highlighting itself part of functionality? or not?

<shadi> [[functionality: processes and outcomes achievable through user action]]

Sharron: I think functionality is involved in the kinds of differences that appear through mouse hover vs a dotted line w/keyboard

<Bim> +1 to Shawn,

Howard: One way around it is to rephrase the current phrase. Instead say check that all visible changes that are triggered by mouse hover are also triggered by keyboard.

Denis: I did not mean the instances where a pop-up defintition appears, but something simpler, where a color change occurs.

<shadi> [[http://www.w3.org/TR/2012/NOTE -WCAG20-TECHS-20120103/F54]]

Denis: there seems now to be nothing that you can fail it against.

Shadi: I am on the borderline with this one. I support to ask WCAG WG. Clarification could be added if they think highlighting is a function. There is Failure 54 as well that might be referenced.

<Zakim> Andrew, you wanted to say leave it in 'keyboard' - we don't have anywhere else imho and to also suggest that menu drop-downs should not necessarily be triggered

Suzette: I think we have two quite different scenarios. If you are looking for an equivalent to hover when tabbing, it should be 2.4.7. But when hovering causes another action such as a definition pop-up or activation it is a question of functional equivalent.

Andrew: We keep it in the keyboard section, I wanted to suggest we look at actions that may occur. Flyout menus for keyboard.

Shawn: I propose that we take this to WCAG, but I would like for all of us to make a comment about their own position about this item.
... one question is that if we need clarification in the Guidelines, we should ask for it. Also from an evaluators perspective you can always say there are Best Practices.

<shawn> http://www.w3.org/WAI/EO/wiki/Easy_Checks_Comments#.5BOPEN.5D_Comment_1_VC

Shawn: Open comment 1VC
... it is about zoom, Background is that when we were at F2F we found that some browsers were wildly inconsistent in the zoom behavior.
... we want to be honest in what we say but do not need to drill down to all specific variances since it is an EasyCheck

Denis: We are talking about browsers but maybe she thinks we are talking of something else. My suggestion is to make clear we mean text zoom

<Andrew> SC 1.4.4 - Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

Denis: many think it is asking too much of developers, but I think we can ask to zoom text only. Making it more restrictive might encourage people to go beyond browser zoom.
... I have had a long discussion with Wayne who you won't be surprised makes a great arguement for text zoom for low vision users.

Shawn: Yes, there is no doubt it is useful but is it required?

Andrew: "text resized" does not say "page resized" if you want to be literal about it, text should be zoomable on its own.

Shawn: Our understanding at this point is that WCAG does not require text zoom, but is a Best Practice?

Sharron: To Andrew's point about text resize seems to offer good basis to make a stronger case in the clarification documents.
... the question is whether WCAG would interpret it that way.

Shawn: Does WCAG mean to require it to work as text only zoom?

<Andrew> G179: Ensuring that there is no loss of content or functionality when the text resizes and text containers do not change their width

Shawn: On this Easy Checks, by the way, we decided to focus on HTML based pages.

<Denis> This is the passage that makes a potential case for browser zoom instead of text zoom: "A user uses a zoom function in his user agent to change the scale of the content. All the content scales uniformly, and the user agent provides scroll bars, if necessary." http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html - Can we please work at blowing it out of existence?

Sharron: I think the problem is in the example, not the intention.
... I think the intention is in fact text zoom

Denis: In the Understanding documents it gives an example from browser zoom. If we can remove that from the Understanding docs, we can make a very stong case for text zoom

Bim: There is a AAA requirement that text be zoomed without scrolling., seeming to be considered but not required at level AA

Suzette: There are many educational products where the zoom does not work, even in the browser zoom

Shawn: Great, it would be good to put these perspectives in the wiki as comments.
... Who will add what for these?
... Denis?

Denis: Creating another issue for this or using the same one?

Shawn: Just so I know when people are done, if you intend to comment on 1VC or 2VC, let's get it in the action item wiki and then note when you are done. So who intends to comment on zoom?

<Howard_> +1

+1

<Bim> +1

Shawn: and when you are done, indicate in the wiki. And who will comment on the keyboard visibility?

+1

<Howard_> +1

Howard: As a quick check, where text overlaps and does not zoom gracefully, that may be relevant.

<Howard_> accessinghighergroung.org - fails zoom

Illustrations for Easy Checks

<shawn> http://www.w3.org/WAI/EO/wiki/Easy_Checks#Recommendations_for_Illustrations:

<Howard_> http://uduc.org/testsite/ - passes zoom for both page zoom & text zoom

Shawn: Did everyone review the background? We have recommendations for illustrations

Denis: Is this for illustrations in the EasyChecks?

AnnaBelle: We are focusing primarily on EC, but I have bigger picture in mind as well.

Andrew: Agreed

Shawn: So then, let's talk about both scenarios then as we go through - may end up with tighter paramenters for Easy Checks

Andrew Reads: "visually separate illustrations from the text flow by putting border and 10 pixel padding around them."

Denis: Really want to go with pixels? why not em?

Shawn: If zooming, the border could get huge

AnnaBelle: I meant between the image and the border

<shawn> http://www.w3.org/WAI/eval/preliminary# contrast

AnnaBelle: in order to accomodate the caption

Denis: it is an important issue from a design standpoint. You would have only one border just not in the image itself

Shawn: image padding border margin - there seems to be general support for that. Can you suggest what a border, padding, margin would be so we can see the rec in practice?

<shawn> http://www.w3.org/WAI/intro/indieui.php

Shawn: Next is don't float images...any objections?
... there is a float on IndyUI so I am not sure we want that rule to be WAI-wide

AnnaBelle: I actually am accustomed to floating images, so that is fine

Denis: I have a problem with the wording of this - for us to say "don't do this because it is complicated" If it is becasue we think it will be difficult to render

Shawn: For EasyChecks it is because we don't need to.

Howard: What do you mean by float, the actual CSS formatting?

Shawn: Yes

Howard: So isn't a float more responsive, why would not want things to float?

Shawn: They need to fall right underneath a paragraph, they are part of the instruction.

AnnaBelle: I like the distinction of Primary and Secondary illustrations. We can say don't do it in EASY Checks because they are primary

Shawn: Next captions

Denis: So do we make the illustrations decorative since we have the captions?

<shawn> http://www.w3.org/WAI/eval/preliminary# contrast

Shawn: look at the images now displayed...each is explaining what is in the paragraph above. Would captions add unecessary complexity/length or do they add clarification

<Howard_> I think captions would clarify

Andrew: The zoom one is actually a caption

<Andrew> http://www.w3.org/WAI/eval/preliminary#zoom

Denis: it looks like text between images in the contrast one

Shawn: Annabelle, what would the caption be for these images?

AnnaBelle: We assume there would be a border that would include the image and a caption, like "Example of insufficient contrast, grey on a light background"

Howard: I think captions will be helpful and not confuse the page, it would not interfere with the flow of the text. If you had a tag under each graphic you would have a reference for each.

Denis: Two things - you worried about overflowing the image which could be addressed with CSS. Also adding captions in this example would in fact add helpful information even if repetitive in some cases.

Shawn: Thanks, any other comments for or against captions? Sounds like lots of support. AB, please add captions to your examples.
... Gray out irrelevant information in the images, and avoid using arrows if possible.

The maximum width is 600 pixels.

Shawn: The exisitng ones are 700 pixels
... the font becomes very small since we are showing screen captures. I can't read the font even at 700 pixels
... Will you think about that, take into consideration?
... let's go through the rest quickly and flag if we need to revisit.
... Please add #9 to your prototype examples

<Paul> #10 not widely supported by browsers yet...

Shawn: ...and #10
... any other comments on illustrations?

Bim: Nitpicking about the fact that figure is an element in HTML5

Shawn: Andrew if you will open up the Action items wiki, we need to assign tasks

ATAG in Last Call

Shawn: It is about to be published as Candidate Recommendation. If we have suggestions, we are already late in providing them.

<Paul> I don't remember either :-)

Shawn: In review I have found some typos. It would be good for us to review from a usability perspective. Howard and paul, you did that for UAAG, planning on doing it for ATAG as well?

Howard: Don't remember but happy to do so.

<Paul> I'll scan it

Shawn: need to review Overview, ATAG at a Glance, and promotion. Who else is willing to take a look at take of these?

Sharron: I will look at Overview and ATAG at a Glance

<Paul> sure

<Sylvie> I can review the documents too.

<Paul> just provide the links

<Suzette2> I will review overview and at a glance

Shawn: Finally, WCAG is open for review. The Updates for Understanding and techniques. There is a question that was unresolved. People wanted one particular note in different sections. EO should weigh in on that.

<Andrew> http://www.w3.org/WAI/EO/wiki/Action_Items</ a>

Shawn: Anything else for now?
... thanks all, plenty to do, thanks for all your help!