EO discussed how to document and track our group and individual Action Items, since the Tracker did not seem to be easy for many members to remember and use. Instead we will use the EO wiki for actions and each member will take more responsibility for updating his/her own Actions. Next the group discussed the Easy Checks Public Comments and agreed as follows: will add a note to translators; no change to include MathML (it is Easy Checks); no change in response to Zoom suggestion since Easy Checks scope currently does not include explanations of why; will change to include illustration of gray text on white background. There was not full agreement on the question of visible focus and members are asked to comment in more detail and to make visible focus arguments on the wiki. The next item was to consider the work that Anna Belle has done on the Easy Checks illustrations. EO members agreed that captions will be useful, not cluttering; floats are OK; Primary and Secondary illustrations are a good distinction. Anna Belle is taking comments and will have new version next week. Finally, the group considered the fact that ATAG is going to Candidate Recommendation and comments, including to the level of typos, are needed. Sylvie has commented and Sharron, Paul, and Howard agreed to review and comment on ATAG in the EO wiki.
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
<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
Shawn: Next comment
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: 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?
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: ...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: 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.
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: 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: 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?
Shawn: and when you are done, indicate in the wiki. And who will comment on the keyboard visibility?
Howard: As a quick check, where text overlaps and does not zoom gracefully, that may be relevant.
<Howard_> accessinghighergroung.org - fails zoom
<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.
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
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: 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?
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: 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
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
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
<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.