Shadi led the meeting and began by observing how few people had managed to complete the survey. He and Eric asked if participants would be able to meet an extended deadline for completing the acceptance questionnaires for the Tutorial work to date. Those in attendance agreed that they would meet the deadline which was extended to June 2 with strong encouragement to complete before that date. Looking at the comments that were made, the group discussed copyedits to the Concepts page of the Tables section, improvements to the Irregular Tables section, considered a suggestion to say sometimes tables are "impossible" rather than "hard" to understand, and more. Considering the overall Tutorials introduction, it was determined that greater emphasis is needed of the fact that for many content providers the CMS will become an important determining factor of success. Rather than try to make disclaimers throughout the tutorials, it was suggested to make a stronger case on the overall Tutorials introduction with supporting references in the individual topics as needed. Tables is an example where accessibility features made with an authoring tool may not be carried over in conversion to the web. In addition, there was support for encouraging Project Managers to think about the Tutorials as a way to provide leadership and resources to their teams. In closing, Eric asks for specific comments on the alt text of the table icons as people do their review. Shadi thanked Eric for his dedication and progress and gave kudos all around to how the group works together.
Shadi: Certain people still haven't reviewed the tutorial drafts, please make time to do that. WCAG-WG is also reviewing the tutorials - to ensure there's no misrepresentations, misinformation. It's important that we have alignment from WCAG working group. We will need to extend review deadline if people indicate they need it.
Eric: OK, we can extend deadline but only until June 2 and would prefer if it is done by Friday May 30. We will then be able to bring up any issues up at June 6 meeting
Shadi: OK, Eric will extend deadline in system, but I want to emphasize how important it is to really meet this extended deadline.
<dboudreau> reference to the email from Shawn http://lists.w3.org/Archives/Public/w3c-wai-eo/2014AprJun/0031.html
Eric: Thanks very much for the
comments in GitHub and elsewhere. They have been very helpful. Let's start with reviewing comments on Tables
Tutorial where we saw the most changes
... look now at Tables Concepts. One section, marked in red is something we have been considering for redundancy.
... seems we have this information in the Overview and the Section "How to Make Tables Accessible" may no longer be needed. Ask the group to read, and make a decision about it
Paul: Reads the section
Eric: The question is do we still need that function since we have the various elements and scope and all in the opening paragraph.
Denis: We should primarily focus on the how to rather than the theory.
Paul: It is also redundant to the Why is this Important section and could drop the CMS bit into what is already there.
Andrew: We might consider putting the section above the complex illustrated one as an intro to that topic.
<paulschantz> great observation
AnnaBelle: I like the fact that the current paragraph explicitly mentions accessiiblity - that makes this section valuable.
Wayne: Yes this ties it all together ...and remember that in teaching redundancy is not always a bad thing.
AnnaBelle: I am willing to make that edit if we agree
Shadi: So the proposal is to merge the two paragraphs, and it seems to me it may go between the second sentence and the end.
<dboudreau> +1 sure
<paulschantz> I agree with that, Shadi. +1
Eric: Yes it is a good suggestion
AnnaBelle: OK I will take a pass at it right after the call
Eric: And what about the last part of that section? The structural coding and CMS reference...where will that go? into FAQs?
Shadi: There seems to be a new paragraph above the section called "Why is this important?" Are we speaking about that section as well?
Eric: Yes I am wondering if those two would merge?
Andrew: Reads paragraph
Shadi: So Eric you are asking how that paragrpah relates to the last paragraph of "How to Make..."?
Eric: Yes, now that we have moved the first part of the section, what to do with the second part.
Andrew: It is useful for those who may be looking at how their CMS relates to the topic
Denis: What Andrew just read would fit with the second sentence of the second paragraph
Wayne: And they are both notes, not central instructional pieces.
<dboudreau> Suggested: Some document formats other than HTML, such as PDF, may provide similar mechanisms to markup table structures. Most word processing applications however do not provide mechanisms to markup tables. Tables markup is also often lost when converting from one format to another, though some programs may provide functionality to assist converting table markup. Many web authoring tools and content management systems (CMS) provide functions to define header cells - table creation without having to manually edit the code.
Shadi: So their are two questions: Should they be put together and/or where should they go?
Wayne: It is tangential to the point here.
Shadi: Paul mentioned it fit with Why is it Important
Paul: Yes, in the part talking
about custom CSS and screenreaders could relate to CMS as
... because it is an aside that addresses various use cases
AnnaBelle: I would like to hear everyone's thoughts before I take an editing pass
Denis: Maybe we could add a third bullet to include authoring tools and finish the section with another paragraph that would use the materials from the end of the red section
<Andrew> +1 to Denis
Howard: First sentence of second paragraph is somewhat confusing. If you did not already know something about Braille it does not really give reasons for why structural coding is effective.
AnnaBelle: We are talking about combining these two and the differentiation is for automated table markup
Shadi: Which is in my mind a very different use case from the first one which is about people using it.
Eric: Those are very good insights. At the top is the Tutorial aspect and below is the importance for users. Having the authoring tools relationship addressed separately is a good idea and may be useful going forward
Shadi: Under How to Make IT
accessible - first paragraph will be rolled into first
paragraph of the page, removed from this
... first sentence of 2nd paragraph must be clarified and relates more to use cases above and Why is this imp
... left with one sentence "Many authoring tools..."
... what is the purpose of this sentence?
Eric: Authors and people who implement CMS may be alerted to see how their systems may support accessible tables and provide a segue for them to seek that support in the systems they use.
Shadi: Make it less daunting,
encourage users of authoring tools that they won't have to do
it all themselves, perhaps an encouragement for tool makers to
... but just one sentence in that section seems odd.
Wayne: I think the sentence is
garbled between data formats and authoring tools. I think we
might want instead to talk about data formats and a separate
sentence to talk about authoring tools and this sentence could
be integrated into that.
... some of this is pretty iffy and it will be hard to make generalized statements about table markup across formats
AnnaBelle: I am glad we are having this discussion. I had not noticed this before and it is very important and very real world. There may be a bit of scope creep but perhaps we must consider some broadening of the scope to address real world situations. So when people come here, they can find solutions that apply to their actual situation
Howard: That type of information might be a bit tangential and would be placed in a side bar in a paper book...not sure how to address that in this context
Shadi: The current Tutorials -
Images and Tables - may be used in different context by editors
rather than developers. One thing you mentioned earlier Eric
was the CMS aspect and how it may relate to other
... so is this something that you anticipate having to reference in the tutorials still to come?
... do we need to reference authoring tools in the overview/intro page?
Wayne: CMS accessiiblity may need to be a tutorial in and of itself
Eric: I don't think we can
address that in our current scope. We might hope for ATAG
tutorials in the future. We do have one sentence in the intro
about CMS (reads it)
... so that is a basic reference in the first paragraph that addresses what authoring tools are and how they can help. I am not yet 100% happy with the reference but it captures the basic idea. In the indivudual tutorials, having a more specific reference on each Concept page may be the way to go.
<AnnaBelle> +1 Eric's idea of having on both home and individual pages
Shadi: So we have a paragraph on the Home page that introduces the importance of authoring tools to accessiiblity and within each Concept page a more specific reference related to the topic of the tutorial
<paulschantz> should be consistent across tutorials; look at images tutorial concepts page. Why is this important section is a clean break from images intro text
Denis: I would not be comfortable giving specific instruction about how to use individual authoring tools - PDF say or Word - to make content accessible
<paulschantz> +1 to Denis' comment
Shadi: Yes agreed, and any specific instruction risks being outdated
Howard: I concur with Denis, we can't provide specific guidance for individual tools. By providing the structural guidelines and must rely on authors to understand their tools for implementation.
<Wayne> I was not proposing specific authoring tools, I just thought a brief tutorial on the concepts of ATAG might be good.
<dboudreau> Wayne - to that I would agree, yes
Shadi: Brief but thorough description on the relation of authoring tools to the tutorials on the Home/Intro page. Now, coming back to the reference on the Concept pages, let's consider this one
Wayne: Can replace the word
processing reference with the more important fact that many
authoring tools do support accessibility
... the sentence about how CMS can be used to insert accessibility features in tables is the more important fact
Shadi: But we don't tell them how.
Wayne: No but we alert authors to the fact that they accessibility supports and features exist within many authoring tools.
AnnaBelle: I don't know enough
about accessibility features to know if we need a specific call out on
this information in each Concept page. But if not, I do feel
strongly that we call it out very emphatically on the Home page,
much more than it is now. If people are hamstrung by the
systems they use, we may not have anything to offer them.
... so the question is do we want to invite people in and teach them about accessibility if they have no capacity to implement in a current work environment?
Andrew: Bringing up the fact that word processing markup may be insufficient and may be lost when converting to HTML is important. Some of the other things they do in conversion will come through. So making people aware of the fact that there may be accessibility issues in the very act of conversion, that sometimes the authoring tool can be effective (and sometimes not), would be useful information.
Wayne: Many CMS can be set to do this but have not yet done so by default. The system may have been set up in a dumbed down fashion and we could raise awareness for tool users to investigate the capacities of their systems and to ask for full implementation of accessibility features.
Andrew: Even if some things are
not fully brought over in conversion there is also the
possibility of doing post-conversion editing perhaps by someone
with higher authoring permissions.
... so those people would benefit and those relying on conversion would at least know to check.
Shadi: So on overall Intro page,
we need a very solid piece about the relationship between the
Tutorials and the authoring tools environment. Given that, the
reference as we have it here on the Tables Concept page, it may
not be necessary to mention it at all. But there were
suggestions about conversions that cause loss of
accessibility that may need to be mentioned here because it is a
higher risk within this particular topic.
... there are specific references relevant to tables that would be useful to keep, and a suggestion that it be done as an aside. Maybe the Tips and FAQ (although that is at the end, may not be as helpful there). That is the summary from my view
<Wayne> +1 to shadi's summary
<AnnaBelle> Agree with Shadi
Wayne: An aside, but I must leave early, so please consider. Irregular tables "sometimes it is hard" can you change to "sometimes it is impossible" ?
Shadi: Enter as a comment?
... Before we leave this, let's all consider the "Real World" which was referenced so often in today's discussion and add those thoughts and comments to the GitHub or other ways that you prefer to communicate that.
Wayne: First sentence, first paragraph
Shadi: Let's consider that suggestion
<Andrew> suggest also adding qualifier - "... without appropriate markup"
<AnnaBelle> I like strength and clarity of word "impossible"
<yatil> Straw proposal: Sometimes tables are so complex that assistive technology is unable to determine which columns or row to associate with a specific header cell.
<Vicki> +1 for impossible
Wayne: When you read "It is hard..." developers think "why not make the AT smarter"
<Sylvie> OK for impossible
Shadi: Wayne raises the fact of blaming the AT, how about it is impossible to programatically determine?
Wayne: However the wording is needed - the fact must be made that it is not the fault of the AT
<paulschantz> I'm ok with it
<Bim> +1 to impossible
Shadi: I see quite a bit of support but I would ask you to enter as a comment
<paulschantz> "may be" impossible
Howard: You will need a qualifier if you use impossible or it will be seen to be hopeless
<dboudreau> yeah.. may be impossible
<yatil> Straw proposal: Sometimes tables are so complex that assistive technology is unable to automatically determine which columns or row to associate with a specific header cell.
Shadi: Yes, need to make the association with broken code
<Howard> +1 to "may be impossible"
<Bim> When the correctural structural markup isn't used it is impossible for ...
+1 to Bim
<shadi> [[Simple tables typically have one header row and/or one header column: For simple tables, mark up header cells with <th> elements.]]
<Andrew> the alt text is good - describes the purpose of the image
Eric: These are not easy to describe for non-sighted people. I added sentences to the paragraphs so there is more on screen context for them. I opted then to have more of a description of the table within the text. I think that is better than trying to do it in alt text
<shadi> [[Simple tables: For simple tables, mark up header cells with <th> elements.]]
<Andrew> alt=" typically have one header row and/or one header column"
Shadi: The question is how does this work?
Andrew: I think it is a good approach. What we see is what is described in the text very well.
<shadi> [[Irregular tables have some kind of heading cell or row that is expected at a different location: For tables where identifying ...]]
<shadi> [[Irregular tables: For tables where identifying ...]]
Denis: Iregular - should it not say column header rather than cell?
Shadi: There are two questions.
First is the approach and I concur with Andrew, it is a good
approach. Second is the question of the content of the alt text
in your comments, please be sure to review and make
... any reactions?
<shadi> [[Multi-level tables have multiple header cells per data cell, most of the time header cells have to be associated explicitly to the table cell: For multi-level tables ...]]
<AnnaBelle> very much like general approach
Bim: There is perhaps more information than the alt attribute really needs
<Howard> +1 to Bim
Eric: There is not a questionaire yet for that
<shadi> [[Project managers will gain understanding of accessibility approaches to help with project planning.]]
<yatil> Wayne: Change "project planning" to "team leadership", "accessibility leadership" or "accessibility team leadership"
Eric: Wayne had a comment about the project manager bullet point. "PMs will gain..." suggested that we change to accessiiblity team leadership or similar. Does it make sense to others since I have no opinion on it?
AnnaBelle: I like the idea of introducing the notion of leadership and team leadership to spark interest and motivation among project managers. They already know they must include project planning.
<Sylvie> I think project management is more simple or accessibility team.
Shadi: Not to get into word smithing here, just consider the suggestion when you complete the survey
Sylvie: Leadership is not a word I often hear in technical work
Shadi: It may be what developers expect to have to be responsible for
AnnaBelle: it is a bit of scope creep perhaps but I find it stimulating. I like the idea of letting PMs know that they can be leaders
Sharron: I don't think it is such a stretch, since PMs are often "Team Leads" and must expect to be able to provide the resources his/her team needs to succeed in accessiiblity
Eric: Wanted to be sure there were no objections
Shadi: There are concerns about the word "leadership" itself but more concensus around the idea of guidance to training and resources
<AnnaBelle> Maybe soften using word "lead"
Eric: in closing, I would ask
people to read carefully through the exisitng tutorials, there
is a new version of the basic structure for the Forms tutorial.
So I woudl ask people:
... first if you have not completed the questionaire, do so please
Eric: second if you have completed the questionaire, take a look a the basic structure of forms tutorials
Shadi: If you finish your reviews, you get more to review. Note that the 2 Jun deadline is a very hard deadline. Eric anything in particular?
Eric: The icon alt text, noting where things don't feel right, places where you trip up where sentences are not just right. We are in the nitty gritty and happy to take comments to really smooth out the presentation etc
<yatil> Questionnaires: http://w3.org/mid/53736E3D.email@example.com
<dboudreau> thanks evreryone :)
Shadi: Great work on this Eric and the group input as well. Love how this group shreds it apart, put it together better than ever. Whole is always greater than sum of the parts, thanks everyone!