Tables tutorial

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

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

Eric: The content of the Tables Tutorial does not yet reflect the changed content. We have a few more things added to Simple Tables and have moved a few other things around so that we have as much contrast as possible called out between complex and multilevel tables.

Andrew: In the first table, looking at the scope attribute, what's happens with the date?

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

Eric: Since it is a very small set of data and the data is distinct, it seems that it might be acceptable to have some duplication of data. It would be different if it was a larger table. So it is divided into small simple tables and large simple tables where we introduce the scope attribute.

Andrew: OK I am happy with that

<shadi> [[think it is ok with the explanation that it is not the most optimal solution -- but we also need to be somewhat pragmatic]]

Eric: So the question to everyone this morning is whether it makes sense to go that route?

<Andrew> maybe "just a few columns" rather specifying "<5"?

Shawn: Small simple table is "....not more than 5 columns" That is pretty arbitrary isn't it? A concern might be that there is not actual rationale for that. I really like having a simple page first but the arbitrariness of the distinction is a bit odd.

<shadi> [[agree with Shawn on removing "5"]]

<kevin> +1 Andrew

Shadi: I agree, I don't think we need to define it so precisely. It should be enough to say a small simple table.

<shadi> [[do we need the heading "example 1" if there is only 1 example on the page??]]

<Andrew> agree - don't need "example 1" text

Kevin: What we have done here is to introduce instruction for how to make the most simple table. But there is the problem of not knowing what to do about the topmost left cell. The issue leads directly into the topic on the next page - the introduction of scope and larger simple table

<shawn> +lots to kevin - mentioning issue on first page pointing to next page

<shadi> +1

<Andrew> +1

Sharron: +1

<shadi> [[+1 to "basic table"]]

Shawn: Any concerns with that? Eric, is that OK with you? What if is a completely basic table, show the use of <th>...with a lead in to "often you will need to do more.." and lead into next pages?

Eric: Yes that works for me.

Andrew: Could we use exactly that same table and make a horizontal rather than vertical orientation that will make the issue more apparent?
... We have column headers in the first row but could instead have row headers in the first column

Shawn: But that is the problem we introduce in the next example.

Eric: We have to consider how it renders

Andrew: So what is the balance between how AT fails to render and the proper application of techniques?

Shawn: Yes we discussed that last week. But what we tried to do was have the first page, first example be as simple as possible, not using scope at the first.

Kevin: I was considering Andrew's suggestion and the fact that doing so leads into what the problem is without applying scope. It does clearly show that even with this simple table we may be introducing confusion that will lead naturally to solving it with scope

Shawn: So no new code snippit but simple a brief explanation of why it may be a problem.

<shadi> Date | 12 Feb | 24 Mar | 14 Apr

<shadi> Event | Waltz | Obleisks | What

<shadi> Venue | Main | West | Main

Shadi: So we are suggesting that by having row headers rather than column headers, we have a different screen reader experience?

Shawn: Yes, as discussed a few weeks ago
... Bim if you have a pointer to that discussion it would be good.

Bim: Well actually there is no difference in the screenreader output but visually it is probably easier to introduce the possibility of confusion.

<kevin> +1

<Bim> +1

<paulschantz> +1

Shawn: Seems there is agreement on having a first page/first example that is very simple but that leads to why you may want to do more and leads to next page

Andrew: Yes, and is there agreement on changing the orientation?

Sharron: So is the proposal to show the first simple table with column headers and code samples. Then to have the same data in row headers and introduce the idea about why it may be a problem?

Shawn: Yes I think that is the proposal.

Shadi: But I feel we have two issues conflated here. First is the problem of date formatting and the second is the syntax, how the tables will be read out loud. From what Bim says there is no difference from a reading outloud perspective.

Shawn: Then why did we say that the Capital Cities had to be on a separate page because it needed scope?

<Andrew> yes - I think capital cities is also a small simple table that could be used on the first page

Shadi: Because of the type of data that makes it more difficult to distinguish one from the other.
... So it seems that the type of data is also a consideration of whether scope is needed.

<Andrew> so - for small simple tables with distinct data types, then the minimum is TH, but adding scope to top left cell adds clarity

Shawn: OK there are still finer details to work out however we seem to have come to agreement on the idea of making the first example into a simple table that requires only th but introduces the idea of why it may be useful to use scope even on some simple tables

<Andrew> what about: first name | second name | city for a confusing example

Helle: If there is no need for the screen reader I don't see the value of changing the orientation. But also is screenreader rendering the only consideration? What about cognitive?

Sharron: Scope will not address the issue of cognitive

Andrew: Are there issues here that we should give to the Cognitive Task Force for their input?

Shawn: We certainly could if we feel that would be useful.

Andrew: So in this case, we might make a reference even though there is no Technque or success criteria that supports that

Shawn: And I am not even sure if there is reliable research that indicates that is in fact the case

Andrew: I could send a few emails to see what research there is

Helle: And I could help with that as well

Shawn: Thanks Andrew and Helle

<Andrew> +1 to shadi

Shadi: I think it is fair to say not having headers or having ambiguous headers is cognitively difficult. So I would suggest Eric that we make explicit reference to the fact that specific headers, separate from the data is useful to everyone. Then we don't need to wait for input.

<Helle> +1 to Shadi

Shawn; So why do we have the capital cities example if it is a method we do not endorse or recommend?

Shadi: Real world example even if we do not recommend it

Shawn: Then we should make it more clear that we don't endorse this method

<AnnaBelle> good idea

<Andrew> yep - add clarity (best practice) is always good

<paulschantz> no objection

<Bim> +1 to add the country/city headers

Shawn: any objection to clearly making a reference to best practice

<paulschantz> +1 to add country/city headers

Kevin: I am a bit uncomfortable putting in an example that does not itself reflect best practice

<shawn> +1 to kevin about not having a bad example

Kevin: I understand that the reality is that people will make tables like this but still have a bit of discomfort in giving it as an example with code.

Shawn: So let's consider if there is a way to communicate the point without showing a bad example?

Andrew: If we had Example 2A be common practice and Example 2B be best practice and only show code for Example 2B?

<Andrew> suggest 'common' and then 'best practice'

Kevin: I like that quite a bit because it acknowledges that this is what people commonly do but we think that 2B may be what you are actually trying to do and that is where we give code.

AnnaBelle: I have done many tables wrong for many years and I am pointing developer friends to the Tutorials even as they are developing. I have learned so much through this process and wish there were some ways within the Tutorials themselves to indicate what we have come through to reach the understanding. Having real world examples is one way to at least indicate that process, so I am in favor of doing that.

Shawn: Eric, so the suggestion is to add a bit more discussion about why we make the recommendations we do and giving the best practice examples

<kevin> +1 "Common practice", "Best practice" titles

<Andrew> my suggestion was for the capital cities eg to have two tables side by side with common practice and best practice but only showing code snippet for best practice

Bim: I like the idea of having a Common Practice vs Best Practice example. The cities/capitals example is one of the earliest ones we adopted and is actually taken from the public web. I see this arrangement often and so think the comparison will be valuable.

Shawn: Because our first example has date as the first column the data is actually quite clear. Perhaps we could have an example where the data format does not indicate what the header should be.

<Andrew> to repeat earlier comment: what about: first name | second name | city for a confusing example

Shawn: so the ambiguity is easier to understand

<Bim> +1

Shawn: and concerns or objections to that idea?

All: None

Shawn: Eric, other questions or items for us to consider?

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

Eric: Yes, please look at new improved Irregular Tables.
... I think the hierarchy has improved. I am now discussing how groups are formed and have made progress, but wanted to know how the organization works now that some of the irregulars have been moved to Large Simple tables

Shawn: Now we have Large Simple and we have MulitLevel, can we remove irregular altogether?

Eric: That is what I wanted to do and wanted the group input

<Andrew> I like the new split

<Andrew> Shawn: should start out a bit more conceptually? rather than getting straight into code discussion

<Andrew> Eric: plan to

<Andrew> ... time intervened

<yatil> https://www.w3.org/WAI/EO/wiki/index.php?title=Tutorials/Feedback/EO2014-06-06#Cognitive_load

<yatil> https://www.w3.org/WAI/EO/wiki/index.php?title=Tutorials/Feedback/EO2014-06-06#Cognitive_load

Shawn: Do you have good pointers, Eric on cognitive to specifically consider?

Shawn: Andrew do you want to explain?

<shawn> current wording "This makes the information easier to understand by everyone and easier to code, too."

Andrew: Looking at the example on multilevel table ...as tables become more complex it becomes more difficult for many people to understand, and particularly people who have cognitive impairments. The cognitive load goes up for low literacy, etc. So split ables might be a useful concept to introduce as an alternative to complex multilevel tables.

Shawn: How much do we explain or reference throughout the rest of the Tutorials about things like this?
... if a certain point is suggested, how much do we say why. Do we say "screen readers do this" or "cognitively impaired users need that..." etc?

Eric: Yes we do that fairly often, however it is usually related as well to WCAG

<Andrew> +1 to adding mobile situation too

<kevin> +1 mobile note

AnnaBelle: In this case it seems to me as well so relevant to how tables render on cell phones. So as long as we connect the dots - that as we make it easier for those with cognitive disabilities we also solve other problems, it would be useful.

Shawn: So Helle and Andrew, are you willing to write up suggested wording to add there?

Helle: I may not be able to be.

Shawn: Could the two of you work on that in the next few days?

Andrew: Happy to give it a try but depends on responses from inquiries

<shawn> addding wording to this https://w3c.github.io/wai-tutorials/tables/multi-level/#split-up-multi-level-tables

Helle: Andrew if you can draft something I can probably add to it since I will have a meeting this week with the cognitive people I know.

<Andrew> and my concern is captured https://www.w3.org/WAI/EO/wiki/index.php?title=Tutorials/Feedback/EO2014-06-06#Cognitive_load

<shawn> Sharron: last week talked about comments on mobile...

AnnaBelle: Developers may also be incentivized by mobile considerations

Eric:

<shawn> ===sub-topic==

<shawn> images & cognitive

Shawn: Andrew, will you walk us through your comments?

<shawn> Suggestion: consider adding a tip that 'alt' is primarily for screen reader users and those choosing not to display images, however as image complexity increases, cognitive load also increases and visible explanations of images are desirable.

Sharron: This is a good point and worth making

<Helle> +1 to Andrew's point

<kevin> +1

<Jan> +1 to Andrew - excellent point

<shawn> diff "visible explanations of images are desirable" -> visible textual information

Kevin: Rather than a simple tip, there might be a need for more explanation of the purpose and the usefulness of the provision of such information
... for example a complex graph in which text will inlcude a summary of the key data points, etc

<Andrew> my example was weather forecasts - selecting city from a map vs a list of cities

<kevin> +1 to Andrew's example

Eric: This topic of cognitive needs may need more mention throughout the tutorials in order to integrate the idea of the reduction of cognitve load throughout

<Andrew> comprehension of the presented information (rather than cognitive load)

Shawn: And rather than continue to use the term "cognitve load" we may discuss the fact that people process info differently and may also need onscreen text as well

Jan: I appreciate the mention of the map and these ideas. Do we want to ask for input from the Cognitive Task Force?

<Andrew> http://www.w3.org/WAI/PF/cognitive-a11y-tf/ - is Lisa the facilitator?

Shawn: The challenge is timing - getting their feedback turned around. So we can ask and see what the response is. We may want to have an alternative plan. So we can submit and run it by them.

Jan: I will help Andrew

<shawn> ;-)

Shawn: Can you draft comments to include in the Images Tutorial? and send to Andrew and Helle?

Jan: So you just want a Tip for considering cognitive issues in general?

Shawn: It should be specifically related to Images in this case. Eric, a tip or within the example?

Jan: I will take a pass and Andrew and Helle, please be encouraged to improve on it according to your vision.

Shawn: Anything else on the tutorials?

Eric: No this was helpful

Planning and Managing Web Accessibility

<shawn> https://www.w3.org/WAI/EO/wiki/Planning_and_Managing_Web_Accessibility

<kevin> https://www.w3.org/WAI/EO/wiki/Planning_and_Managing_Web_Accessibility#Related_WAI_Resources

Kevin: I have started to review these resources and put notes for consideration and discussion. It is a rough indication of what may need changes. There are four Resources being revised and some have not yet been published
... the idea is to review them as they stand and to identify what is missing to develop them further. The goal is to provide resources for organizations that are trying to make their institutions more accessible.
... I want to create some personas so we have a clearer idea of who these resources are for
... I want to find ways that we can carve up the organization and present it in a way that is more meaningful for those who need them
... also identified need. Included questions such as personas with a common need, how does the soultion change depending on the size of the organization?
... I have tried to put key questions to get thoughts from this group about the characteristics of the personas that will help us clarify the focus of the resources. The inital Use Cases were about 12. I have reduced it to about 6 so please consider if I have gone too far in the consolidation. Have I captured enough of a broad cross section of the types of personas who will benefit from these resources?

scribe: Potentially these resources will lead to Modules. My expectation is that the materials here contain most of the content of the Modules but will need to be reorganized into a format that lends itself to learning and application.

Shawn: So right now, we want to focus on the updated personas. Impressions?

Andrew: I like the situation(role)-based breakdown approach - helps folk see what applies to them rather than being overwhelmed and saying "it's not for me"

Paul: Is the idea that people pick the persona that most matches their own situation and then follow a modular path of resources?

Shawn: The personas will not be published but rather to help us make sure that we are considering what resources will be useful to these different kinds of users. While we may do something like this to help people find their way through the modules, we are not expecting these to be published as is.
... actions for all in wiki will be to skim existing resources and read through personas and comment on questions posed

Paul: nice work on this

<Andrew> what about Characteristic of org type? eg government, for profit, non-profit, educational, etc?

WCAG-EM Report Tool

<shawn> https://www.w3.org/WAI/EO/wiki/Feature_requirements_for_Interactive_Guide_to_Assist_Managing_Web_Accessibility_Evaluations

Shawn: A previous name was "Interactive Guide..." and this page lists some specifications for it
... Basically meant as a tool to guide users through WCAG-EM and to generate a report based on data they enter
... we may have a prototype in the coming weeks
... want to get your input and consideration of how to name it.

Helle: Is this something similar to the table or checklist we made years ago?

Shawn: It is not quite that, no. This does not have a report that goes SC by SC inclusive

<Helle> Is it like some of the old check list tools from Eric or the ER thing

<shawn> question for shadi: it doesn't have SC level does it?

<shadi> it can have SC level -- basically it helps the evaluator document whatever they want to include in their report

Shawn: Another action for all is to read through this and be prepared to discuss

<shadi> we'll have a prototype next discussion

Shawn: end of time, thanks for input, watch for actions, have a great weekend?

Helle: Someone in Germany is working on a procurement tool, I believe

<shadi> different from the M376 procurement toolkit?

<Andrew> mandate 376 - now EN 301 549

<Andrew> http://www.cencenelec.eu/News/Press_Releases/Pages/PR-2014-03.aspx

<Andrew> http://www.mandate376.eu/

<shadi> M376 is the activity, EN 301 549 is the standard (outcome) of the M376 activity

Shawn: We are out of time today, thanks everyone for your input, very useful.