<shawn> https://www.w3.org/WAI/EO/wiki/Tutorials/Feedback/WCAG-2014-06-04
Shawn: EO needs to review WCAG submission of comments and the issues they raised to publishing the Tutorials
Eric: I have rewritten the section since the comments were made from Shawn.
<shawn> here is the rewrite: While the main objective of the tutorials is WCAG conformance, we want give developers some advice that goes beyond WCAG and cover other best practices. In this particular instance, the note on mobile compatibility is included because the solution is accessible but adapting it to mobile (i.e. in a responsive context) is not simple and other techniques might be more suitable. We think it is an important aspect to tell readers about the caveats of certain techniques as this should build trust in the validity of the information in the tutorials.
Shawn: OK? If everyone will please consider this rewrite
Eric: Background is that we had a note that image maps are not scalable in responsive design. WCAG suggested that this is not strictly an accessiiblity issue. We want to retain the note so here is the new content. (Reads)
<shadi> "beyond WCAG" -> "beyond minimal conformance"
<shadi> or "beyond sufficient techniques for conformance"
Shawn: If I recall the discussion, EO participants wanted the caveats for general use of image maps made more clear.
<Bim> +1 to additional useful information, as Shawn said.
Shawn: And in general, it is not true that we make recommendations beyond WCAG
... or beyond accessibility so it seems we are saying too much here
... Something like "In general the tutorials focus primarily on accessibility but in this one case we felt that there was a significant conflict that needed to be addressed."
Shadi: Yes, I agree that we want to avoid wording that suggests we are going beyond WCAG. Rather we are saying that this is a special situation in which we want to avoid developers feeling that by implementing accessibility they break effective mobile performance.
<Bim> +1
<Wayne> +1
<kevin> +1
<shawn> http://w3c.github.io/wai-tutorials/images/decision-tree/
Shawn: This was primarily prompted by Howard's comment to make the tree easier to read and follow
Eric: Yes, we have more visual separation by having a two column layout making it easier to understand and follow. I agree that it was a great suggestion and makes it much more clear.
Sharron: I agree, clarity is greatly improved
Kevin: Yes it is more clear, I wonder if the "Yes" and "No" may be the wrong way around. You ask the question and if the answer is Yes, it is done, you stop and you implement as suggested.
... if it is not right form me, is this right for me...no? then I proceed down without having to read the solution since it is not relelvant
Wayne: I did have trouble reading the column layout
Shawn: If it was switched, would it be easier to read?
Wayne: Don't know
Sharron: Well you would have less to read, since you would skip the Yes solution for each one
Shawn: Eric, what do you think?
Jan: Does a screen reader user know to go down in the column
Bim: It is incredibly well designed in terms of screen reader flow.
... just brillian
<yatil> Screenshot swapped: http://share.yatil.net/Screen_Shot_2014-07-18_at_14_50_42_19794FD9.png
Shawn: Eric put a screen shot in IRC for your consideration
Sharron: I like it
<Jan> +1 to flipping yes/no to no/yes
<Zakim> shawn, you wanted to ask "simple"
Shawn: Objections?
All: no
<shadi> An alt decision tree
Shawn: What about the use of "simple" raised earlier by Shadi? Shall we just call it a Decision tree
<Jan> +1 to dropping simple
<kevin> +1 to drop
+1
<yatil> drop, don't stop
Shawn: Is the Decision Tree a term that the primary audience will understand and latch on to?
<shadi> flow chart
<shadi> flow diagram
Eric: I can't think of another term to use.
<shadi> decision helper
<shadi> quick check
Shawn: Alt for my image, how to choose alt text...what else?
<shadi> cheat sheet
<shadi> memory notes
Jan: The Pearson people seem to like it and easily understand it.
Eric: It is a continuation of a term used by Steve Faulkner
Shadi: Who actually took it over from Day Alexander who originated it.
Shawn: Overview page needs just a few tweaks based on recent comments. A copyedit pass for Images Tutorial and Tables Tutorial. Comments are all addressed.
<Wayne> For real credit we should use Donald Knuth
Shawn: Plan is for Eric and Shadi to get those done next week and the final opportunity to review before publishing. Will give people until the last week of July to review for publication.
... so if everyone can plan time to review next week we can address any issues next week since we may not meet August 1. Plan your time to inlcude that if at all possible, OK?
<shawn> background: https://www.w3.org/WAI/EO/wiki/Evaluation_tools
Shawn: looking at the prototype of new database UI
<shawn> prototype: http://w3c.github.io/wai-eval-tools/
<shadi> http://www.w3.org/WAI/ER/tools/
Shadi: Overall purpose is to update the existing list of accessibility evaluation tools. It is old, static, and largely outdated. Bim has collected recent data, Eric has developed a new tool with more interactive function that allows easier exploration of the content.
<shadi> http://w3c.github.io/wai-eval-tools/
Jan: I love it, it seems quite useful although I don't have a lot of experience searching for evaluation tools
Shawn: That is exactly why you are a good audience. To me it looks clear and intuitive.
Wayne: I like the layout, I'm having a bit of trouble figuring out how to activate the filter
Shadi: Can you walk us through what you're doing?
Wayne: Not really, I am too lost right now.
Shawn: Here is a question: Each time you click on a filter parameter, it changes the content - is that clear?
Jan: Not really at first but can figure it out fairly quickly
Shawn: So we should make it clear that as you select, that occurs
... Jan if you had some selected and then you deselected all filters, should it be greyed out or something to show it has been done?
Jan: Yes and when you deselect, it should indicate that it has gone back to showing all results
Shadi: When I select one, plus signs appear among the other selection options. why?
Eric: Because the automated checks includes those other features as well
Shadi: Can we turn that off so that the behavior of the filters is more consistent?
Eric: I am not sure because you could ask for more than one.
<kevin> +1 for always AND
Shadi: If I select both Section 508 and WCAG and there are no results that do both, I will get results that only do one of them. That should not occur.
Shawn: We will get a help file?
Shadi: I am hoping that the UI will be sufficiently intuitive that we don't need a help page to begin to use it.
Shawn: If I have nothing selected, I have 18 in English. If I choose Automated Tools, I have only 6, if I make more selections, I ahve 0
Shadi: Yes, the filter selection status is indicated by the presentation of the button. But I think we need a lead in sentence as well that indicates what the search criteria had been. "You are looking for autoimated tools that check for Section 508 and WCAG and provides In-page feedback. There are x results"
Kevin: I apologize in advance for the fact that I tend to tear things apart. While this is a great improvement over the previous one and the provision of search criteria is brilliant. I am wondering about the way the filters are listed. Is language really the most important thing we will search for?
Shadi: Were people aware that there were more filters below? That you can expand and collapse the filter sets?
Sharron: no not really on first look
Shawn: I did notice right away that there were more down there and that I could expand and collapse them. A separation between the control and the test might make that more apparent.
Wayne: Is the default to have all of them open?
Shadi: No the default was to open only those that are most used raising the question of the priority of search criteria.
Shawn: To play devil's advocate, if they are all opened, it is a huge list.
Wayne: But no, I think they should all be closed and that we should not assume that we know what search criteria they will choose.
Shadi: Manually close them and comment on how it seems
Sharron: Oh yes, much better, much clearer that you must choose your filters
Bim: And for a screen reader, it reduces the amount of reading of lists.
Eric: It seems to me that you are throwing out baby with bathwater here. I would argue that having at least one or two open to make the interface more clear, the function of nested lists of functions becomes more clear. We can modularize to make it more clear.
Sharron: If you visit a few times, that might be clear. But the first time you're there, you might miss it. (I did on first looking at it this morning)H aving it closed it becomes very clear - these are the filters and I can easily see which ones I want. I think having just one or two open adds confusion.
<shawn> +1 to Sharron
<Bim> Just a single line of text below the Filters heading would be enough to explain the closed buttons
Shadi: Having the square boxes as a visual aid is giving me the cue that this is a list of selections to choose from. The arrow is a bit too subtle as well to provide the expand capacity. It is not clearly an invitation to go in and do something
Shawn; At first, I liked some being expanded. It's important to teach people that they must click on the arrows to access any function. Having them all closed makes it entirely necessary to learn that very quickly
<shawn> WORK THIS WEEK: what order should the filters be in? pelase add to the wiki https://www.w3.org/WAI/EO/wiki/Evaluation_tools_comments
Shadi: And to Kevin's second point, the priority of the filtering topics: What are the most frequent filters that people would use to search for an evaluation tool? The use cases in the wiki might help you assign search motives for the various personas. Comment on what you think the order of the filter categories should be?
Kevin: Raising a few questions..
Kevin: Why are we not using checkboxes?
Eric: This was easier to implement
Shadi: Do you think check boxes is a better approach?
Kevin: Yes, if you provide a check box it becomes clear that each selection adds to the filter. Visually the current button selection indication takes up a lot more space.
Shadi: But this is difficult to implement, in realation to the database, is it not Eric?
Eric: OK I will try to make it more visually pleasing.
Kevin: Are we looking to match the style of the tutorial in terms of column size, etc?
Shadi: What is your opinion?
Kevin: It should be more similar
... and it might be beneficial for people to be able to add to the selction list
Shadi: Yes the page is missing some of the context now and is focused on functionality
Wayne: Maybe each of us should list three items in the wiki - one that is at the top, one that is in the middle and one that is absolutely at the bottom
<yatil> Eric: This is the tutorial's CSS and we will see which column size will be suitable in the end, Kevin.
Shadi: Yes we need that feedback , it will be very useful.
Shawn: OK anything else on this topic for now?
... thanks Eric, it is looking great!
<shawn> background: https://www.w3.org/WAI/EO/wiki/Planning_and_Managing_Web_Accessibility
<shawn> establishing responsibilities: https://www.w3.org/WAI/EO/wiki/Working_Draft:_Implementation_Plan_for_Web_Accessibility#Establish_Responsibilities
Shadi: We have spoken about this before. The goal is to update the pages we have for adminstrators, decision makers, those at a level higher than the coders. it is meant to be resources for managers. We have existing documents, inlcuding "Implementation Plan..." and Kevin has worked on a new approach to the topic. We would like feedback on the overall approach.
... think about people who might need these resources, come to these pages, is this tone and format likely to meet their needs?
Shadi: Previously we used a kind of bulleted check list, now trying to provide more context
Sharron: Why are we linked into the section itself rather than the background and intro?
Shawn: Because it is a template for how to develop each section.
Shadi: Don't focus on the content, but on the organizational structure.
Shawn: I think it would *really* help to have another heading that groups similar experiences or situations so that if it soes not apply to me, I would be confident to skip it
Shadi: In each section, is it mind-numbing or helpful to have the repetitive organization?
<metzessive> Is there a reason we shy from pagination?
Shawn: One of the issues is the fact that we are criticized for having documents that are too long. We need to set the expectation that this is not a Quick Guide but a detailed resource
Shadi: Imagining that we will have 10 or 12 sections similar to this. We feel that we are barely scratching the surface and yet there is an expectation that this will be more concise. What is your first take?
<metzessive> +1
Jan: I am very concerned about the length and text heavy presentation. Decision makers in particular are not likely to read all this. I wonder if there is a visual guide, the chunk it outinto sections. The truth is that this is an iterative process and people will enter at different levels. need for it to be more modularized
<shawn> [ yes, it's overwhelming right now -- but maybe with expand-collapse, etc it will be better]
<yatil> s/differnt/different
Jan: making it more consumable will make all the difference, providing a visual aid to how to proceed
Shadi: The detail is for recurrent readers, for those who are trying to actually implement, providing the detail that makes it possible
... I like the idea of having visuals, but have no thoughts about what that might be
<shawn> +1 to breaking it up!
Kevin: I can imagine some instances where visuals might be helpful.
Jon: Back to the pagination section. Perhaps instead of open and collapse, we could make actual pages. I like the idea of visuals and perhaps make them relevant to the topic.
Shadi: So establish responsibilities would be illustrated with several people?
Jon: Yes and identify the management style that is being referenced so it makes sense in a specific environment
Shadi: We would prefer not to be specific about that but to remain general enough to provide useful guidance for all situations. We just can't address all the various orgs of different size and mission, as well as the differnt development methodologies.
Wayne: I appreciate Shawn's comment about the large scope of the project and think that multiple pages are likely to be needed.
Shadi: I have heard that people accept the fact that this will be a text heavy document, glad that I have not heard to remove content but to manage it so it is not as overwhelming. Expand function, possibly pagination, greater visual stimuli, are suggested.
Shawn: I am concerned that as an approach we are including too much. For the first pass, you may actually want to remove content and note to add at a later pass.
<shawn> [ shawn not sure the examples here add enough "meat" to justify the clutter? but I'd need to read more to know ]
Shadi: So can I ask EO to review in the coming week, focussing on the structure and the *amount* of content, the points that have been made in the sections - are they essential? is some critical content missing?
... Kevin will put into the wiki those questions and ask for EO to weigh in. This may take us a step further.
Shawn: And we should put that clear guidance into an email to send out to the group.
<metzessive> where specifically should I be adding my comments to this?
<kevin> https://www.w3.org/WAI/EO/wiki/Feedback:_Implementation_Plan_for_Web_Accessibility
<metzessive> thank you
Shadi: And for those in the front row who need more homework you are welome to review that as well. We are trying to get an agreement on overall approach.
Shawn: For some people the wiki format is more difficult to process. The advantage is to make changes right there. At what point would it be easier for people if it was on a web page?
Sharron: Seems like approach questions are best addressed here
Shawn: But I would like to have the expand collapse function.
Sharron: A WAI resource page or a GitHub?
Shawn: Either one.
<shawn> Anna Belle likes github
Sharron: Yes maybe having the expand/collapse and the ablity to add visual aid would be useful
Wayne: The example of Responsibilities should it not have an ARIA role?
Kevin: We are not considering at this point too much about how the underlying code is structured. Can take a look at it, would prefer to continue to consider content management before doing the code structure.
Shawn: consider the word ratio, the signal to noise ratio. Is information important enough to justify the addition of complexity?
... timing of the quick changes that you might do right way from today's discussion?
... before we ask people to take a review pass or should we send out the call for review today?
Kevin: Yes I will look at moving the side panel up and see if we can provide an expand collapse within the wiki
Shawn: I really don't think that functionality is worth the effort.
<shawn> github if possible - Anna Belle loves it and wayne, too :-)
Shadi: The you will have to change it back again. It may in fact be time to change to a Draft page in the WAI resources or to GitHub. Let's you and I follow up after the call.
... we won't send out the email today
Shawn: Really important document, thanks Shadi and Kevin for all your work on it.
Shawn: There is quite a bit coming up. We will need your four hours a week in the next few months to review the volumne of work. Thanks very much, see you next week.
