In looking at Eric's progress on the tables Tutorials, Shawn noted that only she and Vicki had made documented comments. Helle said she had looked at the Tables Tutorial but had trouble navigating the GitHub interface. Shawn reminded everyone they could still use the wiki and/or email to comment. Eric suggested the group take a look now during the meeting and offer conmments. One major concern is the question of how to promote best practice (for example with table captions) while making the distinction clear between what is required and what is recommended as a best practice. Discussion inlcuded the observation that loading the tutorials with disclaimers and W3C "normative" jargon could seriously undermine the pedagogy of these which are meant to be teaching documents. The group agreed that we want to avoid "noise:" and yet we must make the distinction clear. Several suggestions were offered and Eric will incorporate them for group consideration. Concern was offered as well about the use of terms like "ambiguous tables," Multi-level tables" etc and the group asked for greater clarity, suggesting perhaps the use of "irregular." Next was Shawn's request for volunteers to review the draft of "Indie-UI" with particular attention to the way they reference "use cases" and scanrios. Jan, Helle and Wayne agreed to review. Helle asked that meeting dates be put back on the EO home page, it was agreed to do so. Sharron asked for an update on the WAI response to a request for anayltics. Shawn said Sharron and Liam shoudl submit the questions that they want answered and she will see what we can do. Denis asked for a meeting to continue the Tables turorial review in real time as a group and they settled on a time on May 2 for anyone wishing to join.
<shawn> Eric tutorials e-mail: http://lists.w3.org/Archives/Public/w3c-wai-eo/2014AprJun/0009.html
Shawn: Looks like Vicki and I reviewed and made comments, thank you Vicki.
Helle: I was looking at it too but found I had some trouble getting around in the comments in GitHub
Shawn: You are always welcome to put comments in the wiki or on email
... do you want to make comments now ?
Helle: No I just wanted to say that I found it useful and just what I needed to provide examples to my colleagues.
Shawn: Was it the narrative or the examples that were most helpful?
Helle: It was the code, I am trying to make a complex table accessible and I found the coding examples very helpful
Eric: Let's take a minute to let people look at it again and continue to make comments
... I have two or three things we can discuss today. I was happy for the comments I have received, they indicate we are moving in the right direction
Shadi: Helle, were you saying that you were in a situation where you needed an example and not sure and only found it in the last example?
Helle: I saw the emails from Eric and as I was playing around with my computer in Win7 and was looking at the tables and it turned out to be just right because I was discussing just this with my colleague. I don't have the accessible table coding memorized and so it was useful
Shadi: Were you able to find the one you needed fairly easily?
Helle: Yes, I got caught up in it. I would defintely pass them along to colleagues but then translation becomes an issue.
Shadi: Great, thanks for that
<yatil> https://w3c.github.io/wai-tutorials/tables/simple/
Eric: I would like to hear from the group about the Simple Tables page. This is straight from Bim's previous work. We have captions for the tables but they are not used. So while we promote the caption element, so far we do not use it from the beginning.
Denis: I would tend to agree but would want people to understand that it is not mandatory.
<shadi> [[A table caption can be used to provide a heading for the table as a whole. This is not required to meet WCAG 2.0]]
Eric: Yes, we would promote as best practice, not a requirement.
Shawn: But if we promote as best practice, we should use it in all examples
<yatil> https://w3c.github.io/wai-tutorials/tables/simple/#captionelem-used-as-a-table-heading
<shadi> https://w3c.github.io/wai-tutorials/tables/simple/#captionelem-used-as-a-table-heading
Shadi: So, in Example 3 in Simple Tables that is the first sentence - it is not required to meet WCAG2 but is best practice.
Eric: OK, define captions as best practice and use it in all examples
... if we roll caption example into other examples, we will nto need it as a separate example and the page will be shorter.
<Zakim> shawn, you wanted to ask best practice vs. required
Shawn: Michael Cooper brought up the fact that we should make a clear distinction between requirements and best practice. Have you thought about how to make that distinction - is it made at the time of the example or a note at the end, or what?
Eric: I think we only want to show examples that reflect best practice and can made the comment within the example. I don't think it is too burdensome within the example.
Shawn: But the issue is that if we give an example that is best practice we do not want to mislead people into thinking that an example of best practice is actually a requirement.
<yatil> A table caption can be used to provide a heading for the table as a whole. This is not required to meet WCAG 2.0, but is considered best practice because the caption element is explicitly associated with the table. The caption value should be a succinct description of the content of the table.
Wayne: If we show people what is sufficient we do not need to make a caveat
Shawn: But it is beyond sufficient
Eric: Reads from the text of the tutorial - an example of the "disclaimer"
Shawn: So the question is - will we be that clear on every point where we do that?
Wayne: We are not the WCAG-WG so we can present something that exceeds the requirement without needing to disclaim the example.
Shadi: The question is how to present the example that goes beyond recommendation. It is therefore best to do Example 1 and 2 without the caption.
... then introduce the caption into the more sophisticated examples and introduce the idea of caption as well. The disclaimer may become unecessary then - a judgement call.
... in my opinion it is not worth the noise. In future examples like a widget it may become necessary to have a disclaimer.
Eric: I strongly disagree. When we introduce a technique or practice that goes beyond the requirement we must make that clear.
Helle: I agree with what Eric says - making it as good as possible is important. However, if we send out tutorials that take us beyond what is required, my collegues will skip them - "this is not needed" and it will discredit the use of the tutorials over all.
Helle: I have had these discussions recently and we throw citations from WCAG around because they want compliance and don't care so much about best practice. Context is important.
Shawn: I want to use best practice in each case. However, we must have the disclaimer. Looking at examples of tables if all are captioned, people will just look at them and assume they are needed and put it on the checklist
<shawn> ftr: I kinda agree with Shadi that the first table should be the simpliest
Denis: Approaching it from a client perspective, they are looking for the bare minimum. While sometimes they are interested in best practice making it easier for the user, it is always a lower priority. It must be clear that the extra material is identified as above and beyond the basic requirement.
... since people will not want to read all the techniques etc, this is likely to be a widely used resource. So to show the basic requirement and enhance in subsequent examples with clear explanation, you provide people the choice.
<paulschantz> +1 to Denis...but how to call out "legal" versus "best practice" in the tutorials?
<Helle> +1 to Shadi
Shadi: Sometimes we are discussing specifically the captions and sometimes we move to the general discussion of requirements vs best practice. There are reasons why this is how it is. It is not useful - and could be dangerous - to reinterpret the requirements.
... so in this case, it is not necessary to even mention captions into Example 1 and 2. I agree that we need to be clear about what is required and what is not. Right now we have a specific example adding a caption. Is it really necessary to add the disclaimer ot every subsequent example that uses a caption - I think not.
Sharron: +1 to Shadi
<dboudreau> How about a section at hte bottom of the page titled something like "Going the extra mile" for addiitonal best practices that are not actual requirements?
<paulschantz> +1 to Denis' idea of adding a "going the extra mile" section
Wayne: Actually, coders tend to make templates. They will be happy to see a block of code that meets the example. We often have HTML exmaples that go beyond the topic we are discussing. So if the caption just happens to be there, it is a nice table, easier to follow. It may be irrelevant to the topic within table formatting being discussed. We don't want disclaimers all over the place. Our pedegogy would be derailed and suffer tremendously.
Helle: That is not the case where I live, in terms of coders accepting whatever we give them. They are very particular that they meet the requirement only.
... while coders may do that, the managers will review and say "why did we do that beyond the requirement?"
Denis: Helle's experience is widely shared. But it is our responsibility to show people not only what is required but the benefits of going the extra mile. I worry about that, maybe not in this particular example of captions, but when we start talking about something complex like Forms, we can provide a miserable experience if we only recommend the minimum. Even if this one is simple, when we get to the sophisticated ones, this will be important and we should reach understanding about how we present these.
Wayne: the difference between us and WCAG is that we have a responsibility to educate about the outcome of the decisions they make in the development process.
Helle: Yes, agreed but we must be careful not to sneak in extra without letting people know that we ARE recommending practice beyond the requirement.
<dboudreau> we are in total agreement Helle :)
Shadi: Yes, to make the point that here is the minumum but look how easy it is to make it even better.
... so to move forward, the question is what? To make the best practice disclaimer every time it is used? Is that really necessary or can we clearly make the distinction only once and if necessary cross reference back to that note.
Eric: We really have several examples in Images that "go the extra mile" captions on image groups, etc that are all not a requirement. We do not want to dumb down the examples
Shawn: No one is asking for them to be left out - only to make the distinction between required and best practice.
Shadi: Eric show us an example where we use BP rather than requirement.
Eric: Groups of images goes beyond
<yatil> https://w3c.github.io/wai-tutorials/images/groups/#captions-for-image-groups
<shawn> "a figure element can be used to group those images." i says "can"
Shadi: We have an enumerated list of two and we don't say there are dozens more. If in one of the examples we had a discussion that you could go further. For the most part what we are doing is looking at the minimum for how to address the situation from what I can see.
... so what is the best way. We have lots of table examples throughout the tutorial with captions. Do each of those examples require a disclaimer?
<Helle> +q what is the purpose of these tutorials?
Wayne: This is a non-normative document. It is a teaching document. We can ruin it by putting in all kinds of "normative" "non-normative" and other W3C jargon and people will learn nothing about accessiiblity. There must be enough room for teachers to teach. All of the interference of worrying about being letter perfect from the standards point of view makes for an unreadable document.
<Helle> +q
Shawn: So the question from Shadi is when to put in disclaimers. To answer Wayne, I think we balanced this well in Easy Checks and think we can do the same here.
<shadi> +1 to shawn that <caption> is better to be not an "example"
Shawn: when I look more at this, it jumps out at me that Example 3 should be an entirely separate item and do the qualification within that section.
<dboudreau> +1 to Shawn's proposal to create a stand alone caption page
Helle: To Wayne's point, what is the purpose of these tutorials? They must comply with guidelines to be useful. They are meant to help people conform.
Eric: We had previously decided not to organize by technical feature so I do not think we should make caption a separate page.
Shadi: So the Examples are meant to show the various kinds of tables. Caption is a technical feature. Maybe cut Example 3 down to just the one sentence and focus it more as an example of a simple table than it is now. The caption should be mentioned in the intro to simple tables
Wayne: Maybe in really big, complex sections we must have a section that explicitly identifies that we are balancing best practice vs requirements. Note that we use best practice throughout and let people determine how to integrate.
Shawn: Yes we should keep those options in mind
Shawn: in this case, Summary applies to all 3 categories and Captions apply to all 3 categories of tables. So number 4 becomes "Table Organization" or soemthing and put Summary and Caption within that.
Eric: Yes, we could do that and perhaps there are other things that might go within that
Denis:The terminoly for mulitlevel, complex, ambiguous,etc is not really helpful of even accurate in my opinion.
Shawn: Denis asks about the Multilevel ambiguous terminology...we can decide if we want to talk about this today or next week.
Wayne:Are Thatcher's "irregular tables" the same thing as ambiguous tables. Look at http://wayne.knowbility.org/sceAcc/wcag2Lec02/IrregularTable.html
Shawn: before we do that, where are we on the two issues: how to reference requirement vs best practice in general and how that decision is applied to this question of captions within the table tutorial?
... Eric do you have a straw proposal for how we might address this within captions?
Eric: Remove caption from Example 3, not sure about how to have the "go the extra mile" comment in each example or as a separate note
Sharron: +1 for NOT putting a disclaimer in each example
Shadi: It is also not a good idea to have an extra mile separate page
Eric: A "Best Practice" section on each page, maybe in a box?
<Helle> +1 to Shadi
<yatil> [[(This is best practice in most cases, though not a requirement because a form control label can be associated in other ways.)]]
Shawn: We have the sentence in Easy Checks, maybe 3 or 4 times.
Eric: Yes but that is not the problem we are solving. If we look at an example, and there is a caption, people will think it is a requirement.
Jan: I like the way captions are currently noted in the tutorial - it already says that captions are best practice. I think that is enough and that putting it in every example is too much noise.
Shadi: The way it is now, it is somewhat buried. If we draw that sentence up to the top or soemwhere more prominent then in this particular case of captions, that will be sufficient. At least in the intro we should mention and if Example 3 is left in, it is rephrased.
Denis:
Shadi: We have a section that says
[[A table caption can be used to provide a heading for the table as a whole. This is not required to meet WCAG 2.0, but is considered best practice because the <caption> element is explicitly associated with the table. The <caption> value should be a succinct description of the content of the table.]]
That sentence should be moved or at least repeated in the intro to the Simple Table. In addition Example 3 can be dropped or rephrased as a situation of a table that is improved by adding a caption. "Table that needs a caption" or something like that.
Shadi: we will have everything clearly identified - the minumum and the example of how easy it is to do best practice without needing further clarification.
Denis: We should not have caption here unless we have it everywhere - I am in favor of either having it everywhere like that (not preferred) or making it separate (much preferred)
... the second and third examples, I would remove the third
<shadi> for eric: change "Also use the <caption> element to describe the overall topic of a table." on the "Tables concepts" to "Also, the <caption> element can be used to identify a table."
<shawn> +1 to Denis on removing from Simple Tables the third example
Helle: I think this is good, it is becoming now a little confusing whether we should make it part of the simple table into or make it separate like Denis suggests. I am not sure how to choose. We should think about ti for a week and come back.
Bim: Can we go back to Shadi's suggestion of having an example where the heading is needed in some situations? That makes it sound like the caption is required in some instances and it is not.
Eric: Yes, I understand that
Shadi: I think Eric has enough info to make a decision and bring it back to the group. It is not a requirement but it is there for a reason.
Bim: Yes, I think that is true of many tables. Without a caption many tables are confusing, but it is not ever a requirement
Shadi: Yes perhaps it is worthwhile to have the discussion in a separate page.
<shadi> +1 to Bim
Shawn: And it is incredibley useful information that Bim just gave us. So we can use those two examples as a way to help others understand.
Denis: What if we add on other pages a bare minimum version and an extra mile version.
Sharron: I would want us to be cautious only because people night choose bare minimum by default, but we want them to see the best practices so they get the good stuff and see that in some cases it is not a significantly greater effort to do.
Shawn: That is an interesting idea and can be considered in some form although with current resources we could not do it now. But we should think about how that idea might lead us to soemthing we could do.
<dboudreau> agrees that I may tend to be a little bit of a scope creeper at times :)
Shawn: Eric, do you have enough information to take a next pass at captions and the best practices issue as it relates to Tables?
Eric: Yes, I will offer another approach for next week
<Wayne> http://wayne.knowbility.org/sceAcc/wcag2Lec02/IrregularTable.html Jim Thatcher
Wayne: My question is whether the ambiguous table is similar to Thatcher's Irregular Table?
Eric: Yes it would be one example of what I have in mind.
Wayne: I have used this example in the past and it seems aligned with what you are getting at
Shawn: Great thanks for the brainstorm. And Eric is there anything else you ened us to consider in the Tables Tutorial this week?
Eric: No I just wanted to let you know there is an edit button on GitHub for those who want to use it.
Shawn: And there are also comments in the wiki and we are happy for your to implement and only bring to the group for discussion anything that you have doubts about.
Eric: OK
Shadi: I GitHubbed this week...and it was great. If I can do it, everyone can. I was not sure about the Fork and MiddleMan terms but I ignored them and edited just like in the wiki and sent to Eric. So forget the jargon and just edit away. It was GREAT!
Shawn: I think many of us will find this interesting. It is case studies, scenarios, what users need, how needs are addressed by IndieUI.
... Wayne has stepped up, who else is interested? We did not get to review before it went our unfortunately but now is the opportunity.
... who wants to review? The timeline is to be done within a month, by 23 May or so.
Jan: What to look at?
Shawn: The requirements for the Indie-UI
Jan: I can take a look at it
Helle: I will try and look through and see what's in it...I may not have the time for deep review
Shawn: That's fine, just make a note of what kind of review you ahve done.
Wayne: What to focus on?
Shawn: As usual, the intro, abstract etc. But in this case, there are Use Cases that we may need to look more carefully at. But in general you should probably skim the whole thing and focus on what catches your attention and interest. For example they use Use Cases AND Scenarios which adds clutter and confusion. We could help clarify
... we could also look at Use Cases and see if they meet all examples. And comment in whatever fashion works best for you.
Wayne: OK thanks, I understand and know how to read this
Sharron: Any update Eric?
Eric: No
Shawn: The W3C Systems team wants to know what questions we want answered
Sharron: OK, thanks
Helle: On the homepage of the EO page, can we please have the meeting dates?
<shadi> +1 to Helle's suggestion
<Helle> ++1 to Shadi
Shawn: Last Tuesday, Eric sent a note about the Table Tutorials - they need review and comment. Everyone please spend time doing that review.
... in terms of the other work, our central focus is the Tutorials to provide Eric and Shadi the feedback they need as rapidly as possible to get them done and get them out ASAP. We have some wrap up work on other things but this is our central focus. any thoughts on that?
Denis: Can we plan an hour or so with Eric to simply focus on the tutorials rather than being incremental?
... I find it more difficult to do on my own. If we can commit to do a work ssession so that other things do not get in the way?
... Some of the discussions we still need to have are conceptual and benefit from live discussion
Shawn: vs some of the comments I put in the wiki are not discussion items
... what are the topics for the telephone work session?
Denis: In thinking of new ones and approach to them or finishing these? If we are going to discuss the way we organize the tables tutorial for example, it would be better to discuss rather than spend hours in the wiki
Eric: Not sure if it is beneficial to have more talking..I generally like to focus on the code rather than phone calls. The next two weeks are very short for me - 3 working days each of the next two weeks. Maybe after that we could schedule a weekly meeting.
Shawn: There is nothing to stop several people from doing their review of a Tutorial as a group
... any other questions, comments, ideas? Thanks all for a good meeting we'll look forward to an update next week and have a great weekend.