Education and Outreach Working Group Teleconference

06 Jun 2014


The meeting began with brief introductions of new EO participants Jonathan Metz and Kevin White.The rest of meeting was spent considering the WCAG-WG comments on the Tutorials. Eric brought to EO those comments that needed group considerations including the following:

EOWG participants are advised to stay alert to Eric's edits this week and be available to respond quickly. Thanks all!



Kevin, Sharron, Shawn, Bim, EricE, AnnaBelle, Jonathan, Jan, Paul, Howard, Sylvie Duchateau
Wayne, Andrew, Shadi, Denis, Helle. No survey results from Andrew, Liam



All: brief introductions for new EO participants Kevin and Jonathan

Tutorials-Tables organization

<shawn> https://www.w3.org/WAI/EO/wiki/Tutorials/Feedback/EO2014-06-06#Mention_text-only.3F

Shawn: Thanks to those who have commented...take it away Eric.

Eric: Yes the contributions by everyone have been great and I want to say thanks and acknowledge that. Feedback from WCAG said it was not clear in the Tutorial what Simple Tables really are.

<yatil> https://w3c.github.io/wai-tutorials/tables/simple/#table-with-header-cells-in-the-top-row-and-first-column

Eric: we defined it as those that only need th not scope But WCAG-WG felt that some simple tables actually would need scope, for example, the second one.

<yatil> https://w3c.github.io/wai-tutorials/tables/irregular/#table-with-header-cells-in-one-column-only

Eric: so now we are in a bit of conceptual trouble since we wanted the simple tables to be as simple as possible but we also want precision and accuracy. A second example was one in the Irregular section that looks very simple but really requires the scope attribute.
... the argument in favor of restructuring the sections would be to clarify those kinds of gray areas.

Shawn: If I understood correctly, in the current Simple section, the example has both row and column headings and so would need scope.

Eric: Yes that was their advice, but I do not agree.

AnnaBelle: I agree with you....what was their reasoning?

Eric: Table 2 with row and column headings needs because it is insufficient without it.... because of technique H63

<yatil> http://www.w3.org/TR/WCAG20-TECHS/H63.html

Jan: Didn't Wayne say that he too agreed with that - that both were needed?

Eric: I don't remember that but will look.

<shawn> Shawn: our advice is out of synch with some of H63 "For simple tables that have the headers in the first row or column then it is sufficient to simply use the TH elements without scope"

Bim: I have tested and must agree with WCAG on this issue. The screenreader reads all of them. Since a screen reader can't determine direction otherwise. So finally I believe that scope is generally needed to assure clarity for screen readers. On the other hand, I think they should beef up H63 to make the importance of scope more evident. We look at "scope" as required and as optional.
... it should be required. The impact depends on the size of the table, but for example the very first table. If I am in the last column and navigate up to the top, I will hear all of the headings read out. In this case, it is not a problem but in larger tables it can be.

Shawn: Sylvie, what is your opinion?

Sylvie: I am not so technical. I look for how it works for the screen reader but cannot relate it to the code as well as Bim.

Shawn: Any other perspectives?

Kevin: What happens when you have several headers in a single row, is it reading out in that order - the order of the columns?

Bim: It is not deliberate. The screenreaders rely on the programming to know what headings should be read. I have mine to read all marked headers.

Shawn: So some of that behavior is due to your settings?

Bim: Yes, but the alternative is to read top row and left column as headers and in these examples that would be worse.

Shawn: So it sounds like we have a disconnect between the Techniques and what the Tutorials are recommending.
... Eric what is your response?

Eric: Clearly we need to introduce scope earlier, on the simple table page. If so, we will recommend scope to be used in *MOST* tables and will be in alignment with WCAG. We will then be saying to use scope more often, even perhaps always to use scope.

Shawn: So if there is just one header row, should we say "use scope"

Eric: No, but should introduce in the second example.

Shawn: We did due diligence in saying that if there are row headers in a column, we need to introduce scope, but that is not what Technique H63 recommends. So from our current perspective do we want to say if there is just one row of column header (the first row of cells). IN that case do we want to say scope is not needed?
... and if there is only one column of row headers, do we need scope in that case?
... and if there are both, we need scope.

Bim: May I give another example. If I am in a calendar and move to the top row to hear what day of the week I am in, I will hear all of the days of the week announced.
... if scope is not used

Shawn: How much do our recommendations have to be based on the settings of the AT and how people use them rather than the actual capacity of the AT to properly render.

Howard: I just did that and it read fine.

Bim: What browser?

Howard: Firefox

Bim: FF is different

<Howard> firefox with NVDA

Sharron: I have concerns about trying to mediate for the fact that people don't know how to use their AT. Authors can't really be expected to code for screen reader and user idiosyncracies.

Kevin: I can appreciate both arguments but since the question is what to do in the Tutorial, the first example will work OK without the use of scope.
... we could introduce scope prior to the second example as a best practice. Wonder if it might be worth doing something like that.

Shawn: The challenge is whether to say what the recommendation is but also aligning it to the actual Technique.

<Sylvie> NVDA works better with Firefox.

Howard: Testing in NVDA in IE moving to the top row, it says "date, column header venue"

Shawn: So should we rather file a bug rather than shape our recommendations around that behavior?

Sharron: +1

<kevin> Kevin: +1

<Bim> +1

Sharron: Bim said something earlier about referencing best practice, and I agree also based on Helle's insistence that we separate BP from requirements.

Shawn: So with that perspective of separating BP from requirements, what do we do about the second example?
... WCAG said scope was a requirement in that case.

Eric: That is a tough one, since AT should be able to read properly without scope but since it does not...may be needed.

Shawn: And what about the irregular / simple table example?

Eric: Yes AT should be able to read properly without scope

Howard: So what about more of what Sharron was suggesting about discussion of variance in AT support and user settings

Shawn: Let's consider what we will say: Something like what the AT should be able to do well and what they don't balanced against the fact as Kevin observed that this is a tutorial and we want to be simple at the start. So shall we do the first one with just "th"? And after that, we introduce scope and all the rest of the tables have scope?

<yatil> +1

Sharron: +1

<kevin> +1

<AnnaBelle> +1

<metzessive> +1

<Jan> +1

<Sylvie> +1

Shawn: Having said that, look at the structure. Originally we had the sections divided by what is needed. First was only th, second was scope, and finally with more complex headers, id etc. So where we are now with the current structure, do we want to maintain that?
... or change the organizational structure?
... moving scope into the very first page?

Sharrron: So if we keep the current structure, we would have only one example and change the icons?

AnnaBelle: After listening to Bim, I think scope needs to be brought into page one just for consciousness raising.

Shawn: But then why have three pages in that case? First page could be th and scope and second could be more complex.

AnnaBelle: It is more of a more impressionistic thing. The way they look is more important in separating simple & complex in this case than how they are coded. People will be thinking of presentation rather than code.

Howard: Why not get rid of the word "complex" in front of Irregular

Sharron: +1

<kevin> +1

Shawn: So we have two options: One is to keep three pages. 1st page would keep example 1 and example 2 and would pick up example 1 from irregular and would introduce scope in the intro and use it for all but example 1.
... the second page would have no new information and would only include what is currently example 2 and 3. Third page would not change.
... Second option is to make the first page only introducing <th> and only containing one example and have a name change. Second page would introduce scope as it does now pull over example 2 and have a tile change. Third page does not change.

<AnnaBelle> I prefer option 1

Shawn: Thoughts on the two options?

<Howard> +1 option 1

<Jan> +1 option 1

Sharron: +1 to option 1

<Sylvie> +1 to option 1

<Bim> +1

<shawn> +1 to option

<kevin> +1 option 1

<shawn> +1 to option 2

Eric: What if we move the 2 examples on Irregular tables to the third and be renamed "Complex Tables"

Sharron: So we would have only two pages - Simple and Complex?

Shawn: Yes but then we will have two concepts on each page?
... the first page will introduce both <th> and <scope>. The second (complex) would introduce scope column span as well as headers and ids
... it seems to me this makes it more complex. Now on each page you must learn multiple things

<AnnaBelle> understand concern :)

<Howard> I understand the concern

Shawn: Currently the student learns just one concept per page. The suggested reorg makes the student learn more than one thing and prompts them to make decisions about multiple things within each page

Eric: Understand and share concern, but not sure how that can be addressed in this structure?

Shawn: But maybe we don't need to keep the current structure and can rethink...maybe something like "Header in Top Row", "Headers that need scope" and finally complex or multilevel tables

Howard: Simple, irregular and complex are conceptually so much easier.

<Bim> +1 to Howard's suggestion simple, irregular and complex

Sharron: +1

<shawn> Shawn: agree it looks better, but does not as accurately describe the proposed content

Shawn: Eric, what additional information do you need from us to try an alternative organization?

Eric: I will go with option 1 for now and see how it works out.

Shawn: A snapshot of this would be useful to archive and you can put the snapshot under /WAI/EO/Drafts/tutorials

<shawn> h63 "Note 1: For simple tables that have the headers in the first row or column then it is sufficient to simply use the TH elements without scope."

Shawn: So the reference to H63 may not be able to be pointed to. Bim I wonder if you can summarize the discussions we have had in the past about headers in first column, submit to Shadi, and see if we can submit as a technical comment?

Bim: Yes I will be happy to do that.

<yatil> https://www.w3.org/WAI/EO/wiki/Tutorials/Feedback/EO2014-06-06#ImageMap

Image Maps

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

<yatil> https://w3c.github.io/wai-tutorials/images/imagemap/##mobile%20devices

Eric: WCAG observed that our note - that image maps do not function correctly on some mobile devices and that we suggest redundant text links - is unecessary since it is not specifically an accessibility issue.
... what does the group think? is it unecessary, should we remove?

AnnaBelle: I find it helpful information in general. I have run into that situation and this is great to know.

Paul: I find this useful as well but they are right that it is not accessibility, so OK by me to pull it.

<Jan> +1 Annabelle

Howard: It is a useful tip, I would keep it and the fact that it is a note makes it clear that it is peripheral but related.

Sylvie: I have not seen image maps on a phone but since the use of phone as a browsing device, I don't think it should be removed.

Shawn: Their point is that when it breaks on a phone it breaks for everyone and so it is not accessibility related.

Bim: I think that note is a leftover from when I was editing. I put it there becasue it was part of the mandate from the WAI-ACT project to give useful tips about behavior on phones and devices.

Sharron: Totally agree with leaving it in.

<Sylvie> I think as long as it is a note, it is a useful tip and could remain.

Eric: I agree with leaving it in.

Jonathan: I am in favor in taking it out. What happens if mobile technology improves to be able to render properly?
... there are lots of things that mobile devices don't handle... will we mention all of them?

<AnnaBelle> maybe call it "Tip" instead of "Note"?

<kevin> +1

Kevin: It is a useful pointer and I understand that there are other things that mobile tech does not do well, but this one seems easily addressed.

<Jan> +1 leave it in because it speaks to a technique that works today with current technologies.

Shawn: We have always tried to draw the line and include only things that disadvantage users with disabilities to a greater extent than other users. Using that criteria, this should not be here. On the other hand, this is a Tutorial, not a WCAG guideline or even a Technique. We do not need that strict of a scope. Personally however I would lean toward removal.

Eric: Another option rather than a Note within the body, we can move it to the FAQ and Tips page.

<AnnaBelle> +1 to eric's suggestion

<shawn> -1 to moving it to tips & faq 'cause it would give it more general visbility

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

<metzessive> I think the tips page is the best place for it.

Shawn: Any comments on including but moving it?

AnnaBelle: I find it helpful. It is short, useful, easy. I think it is better in context rather than in an FAQ but I don't feel strongly about it.

Jonathan: The FAQ page is the better choice in my opinion.

Shawn: What about the fact of seeing it in context

<Howard> +1 to AnnaBelle

Jonathan: We could reference it in context and link to it.

Sylvie: It is important to talk about it in the context. Some will not think to look at the Tips. Could even make the disclaimer that it is not an accessibility requirement.

Jan: It is important to leave in and I prefer it in context.

Eric: I am in favor of leaving it in and leaving it where it is.

Shawn: Any objections?
... then Eric you will need to write up a draft reply to justify our recommendation to leave it in.
... for things that we are NOT doing that they suggested, send us the draft of the response so that we can all agree and approve it.

Table Summary

<yatil> https://www.w3.org/WAI/EO/wiki/Tutorials/Feedback/EO2014-06-06#Summary

Eric: The comment is that we should not give html4 summary such center stage but should focus on html5 solutions. I am not sure that makes a lot of sense.

Howard: I was surprised as well that a deprecated attribute is given such emphasis. I agree to minimize rather than remove the reference however.

<Sylvie> +1 for idea of summary

Shawn: What about including the summary html4 attribute and also the fact that there are other ways to summarize tables using ARIA. So what if we change to heading so that rather than looking at the attribute, we can reference the capability of using various ways to summarize table structure and/or content.

Sharron: +1

<AnnaBelle> +1

Kevin: The title is "Captions and Summaries." This means that an element and an attribute are given equivalence. So I think a title change will be needed.

Eric: I agree with the idea of making various ways of providing summaries but not sure I agree with the title change.

<shawn> https://www.w3.org/WAI/EO/wiki/Tutorials/Feedback/EO2014-06-06#ARIA

ARIA references

Eric: WCAG suggested that we have more about ARIA on images page (for example role="group") Bim said it works very well in IE but not so well in FF so we may have another instance of what the AT supports and that it is situational. A note may be needed.

<yatil> https://www.w3.org/WAI/EO/wiki/Tutorials/Feedback/EO2014-06-06#Groups_of_images.2C_ARIA_example

Shawn: The summary was that WCAG suggested adding compatibility information...support in wiki, any objections?

All: none

<shawn> https://www.w3.org/WAI/EO/wiki/Tutorials/Feedback/EO2014-06-06#ARIA

<yatil> https://w3c.github.io/wai-tutorials/tables/caption-summary/#use-aria-describedby-to-provide-a-table-summary

Sharron: If using an HTML4 document and add ARIA, the code won't validate. WCAG objects to our wording... saying it is "not valid" in HTML4 may give the wrong impression, that it breaks in HTML4 which is not quite true. The wording here is easily misinterpreted to give the impression that ARIA does not work with HTML4. In fact, AT will find and use ARIA as easily in HTML4 as in HTML5 - it is only that the code will not validate in HTML4. So if we clarify that ARIA will still be rendered and used by AT when inserted into HTML4 but that it will generate code validation errors, we will be more accurate.

<Howard> +1 to Sharron's clarification

<kevin> +1

<AnnaBelle> +1 to Sharron

Shawn: The proposal is to better clarify that it is OK to use ARIA with HTML4 and that it will probably render OK with most browsers and AT but you may have code validation errors.
... any objections?

All: none

Eric: WCAG was surprised that "in general" we did not provide more frequent recommendations for ARIA. Not sure how to address

Sharron: Since ARIA is meant to be a kind of second line tool - remember the specs themselves say to use HTML alone when that adequately provides accessibility - I think we are right to emphasize HTML solutions. I expect as we get into more complex interactions we will find places to talk about ARIA that are more appropriate.

AnnaBelle: I love that we are including ARIA incontext where it is most useful rather than as a an add-on.

Shawn: Sounds like the reply may be we have looked at where ARIA may be appropriate, we welcome your suggestions and we expect that we will use more ARIA recommendations in future tutorials.

<Bim> +1 to Anna Belle

<kevin> +1

Shawn: where it is useful and appropriate

<paulschantz> +1

Cognitive Load

<shawn> https://www.w3.org/WAI/EO/wiki/Tutorials/Feedback/EO2014-06-06#Cognitive_load

Eric: Suggestion from Andrew that we might mention that simplfying tables can reduce cognitive load and adding images can help for cognitive issues and a few other places

<yatil> https://w3c.github.io/wai-tutorials/tables/multi-level/#split-up-multi-level-tables

<paulschantz> +1 to Andrew's suggestion, the reduction in complexity really stood out to me

<yatil> [[It's often possible to split up a complex table into multiple simple tables, which is usually better for users and easier for coding.]]

Shawn: Perhaps we can discuss further next week when Andrew is able to join the meeting

Images Tutorial FAQ

<yatil> [[Shadi: "Consider an FAQ [in the images tutorial]: "I've been told text-only pages without images are more accessible" (may need to be discussed with EOWG if this is a good or bad idea)."]]

Shawn: A suggestion was made to include a comment on the idea of text only being a good alternative for accessiiblity

<shawn> If we decide to do something like this, suggest different wording, e.g., "Should we provide a text-only version without images?" or such that does less to perpetuate the myth by itself. (also note it will take a little effort to craft a good, succinct answer) {Shawn, 2014-Jun-06}

Shawn: the question is if we want to address that here?

<shawn> a/If we decide/wiki comment: If we decide/

Bim: I think it is a great idea as a double myth-buster. First that images are a problem since if appropriate alt is provided, images are no problem for screen readers. Second that accessibility is all about blindness since graphic content helps many other kinds of users with disabilities.

Jonathan: plus 10,000 because I rely on visual input

Sharron: The only reason not to use that question is that when people skim they might have that misconception reinforced.

Shawn: Yes could perhaps turn the question around to say "I have heard that text only is not good for accessibility?" Eric please take a pass. We are the end of the time, please look at the wiki for updates and keep up with homework

Sharron: Question: How did we do on survey participation?

Shawn: Not that good, unfortunately
... thanks everyone, good points, good input on tough decisions. Try to plan some time on Thursday to review the changes for next week.
... good job all, bye now!

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014/06/13 18:41:28 $