Tutorials Questionnaire

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.

<Sharron> +1

<Andrew> +1

<Bim> +1

<dboudreau> *waves*

<Wayne> +1

<Howard>+1

<paulschantz> +1

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

<yatil> https://w3c.github.io/wai-tutorials/tables/

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.

Denis: agree

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

<Vicki> +1

<Andrew> +1

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

<Sylvie> +1

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?

<yatil> <https://w3c.github.io/wai-tutorials/tables/##Some+document+formats+other>

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 well.
... 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 follow ATAG
... 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 tutorials
... 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?

<yatil> <https://w3c.github.io/wai-tutorials/##Authoring+tools>

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

<Howard> yes

<Vicki> 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

<Vicki> +1

<yatil> +1

<Howard> +1

<Andrew> agree

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.

Irregular Tables

<shadi> https://w3c.github.io/wai-tutorials/tables/irregular/

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

Alternative text for icons on Table Tutorial

<yatil> https://w3c.github.io/wai-tutorials/tables/

<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 suggestions.
... 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

Cover Page for all Tutorials

<yatil> https://w3c.github.io/wai-tutorials/

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.6020707@w3.org

<paulschantz> thanks!

<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!