Web Content Accessibility Guidelines Working Group Teleconference

24 May 2016

See also: IRC log


AWK, Kathy, Laura, jeanne, KimD, alastairc, JF, Joshue108, SarahH, Makoto, David_MacDonald, Mike_Elledge, Greg_Lowney, kirkwood, MichaelC, Katie, Haritos-Shea


Hello. I am not able to get into the teleconference.

* Thank you.


<AWK> akim, agenda?

<Zhang_Li> hello everyone~

<Zhang_Li> what's the password of today's meeting?

<AWK> zakem, agenda order is 1, 8, 9, 10, 6, 7

<scribe> scribe: Rachael

TPAC Registration https://www.w3.org/2016/09/TPAC/

<SarahHorton> Traveling a bunch until July but can scribe July 5

TPAC registratoin is in Sept in Portugal. We are meeting and encourage people to attend. Registration is currently open

WCAG is meeting on Monday and Tuesday of the week.

Wednesday is the technical plenary day. Can give overview of big issues W3C is focusing on. Possibility of breakout sessions.

For some working groups you have to be a member, not an invited expert. If not a member, you need to get persmission of the working group. Not usually difficult but ask before booking.

Mobile TF survey: https://www.w3.org/2002/09/wbs/66524/2016-0509/ - please find some time to provide feedback

Mobile task force with Kathy and Kim remind you that they want your feedback. This survey includes everything you need to look through and respond.

<MoeKraft> Can someone share the webex password? I tried w3c but that fails. Not seeing anything in the irc header. It scrolls off screen as soon as a new message is entered. Thanks, Moe

Kathy: Thank you to those who have responded. We are looking for feedback to further refine this.

<MoeKraft> Let me try again. I think I entered into the wrong field.

https://www.w3.org/2002/09/wbs/35422/17thMay2016/ (Question 1 only)

<AWK> https://www.w3.org/2002/09/wbs/35422/17thMay2016/results

<steverep> Would be happy to try scribing in the future, but I may miss some content having a screen reader in one ear and the telecon in the other

Question 1 on this survey. This question has been on our radar a while. Would like to get it figured out. Question on heading areas, footer areas, asides, etc. and whether they need to be programatically or explicitly identified in text. Is this required or not requred by WCAG 2.0?

<davidmacdonald> https://github.com/w3c/wcag/issues/173

4 people say yes, 5 people who say no. 7 people say we're not sure.

Some say it depends on visual formatting or content.

We want the best user experience but recognize that WCAG doesn't address everything to create an ideal experience.

<davidmacdonald> Add 1 to the yes side

<davidmacdonald> Add David and Katie = 7 to 7

Katy (Yes side): For those things that are visually apparent, she believes they are required.

Marc: When I look at it, I see structure conveyed through presentation needs to be programmaticaly determined. Most web pages are structured w/ header, footer, etc. These are all visually, easily identifiable so they should be programatically identifiable. If someone moves them around it is still visually apparent so should be programatically apparent.

<Zakim> steverep, you wanted to explain my yes

<Lauriat> I can speak to my own view of the no side, even though I disagree with it.

<marcjohlic> +1 to a Failure around leaving orphaned content when you use landmarks on a page

Steve: If its visually apparent, the criteria requires this. From a screenreader user perspective, there needs to be a push to use landmarks. When they are missing it is very frustrating. I see alot on webpages when someone only marks up the header or the footer. It should be appropriate to require that there is a main section not just a footer.

Moe: Echo what Steve is saying. It does assist in navigation but also by programatically conveying structure, it gives a screenreader user something that those who are sighted take for granted. The landmarks are essential.

Marc: I really like the idea of a failure around the idea that if you use landmarks on a page, they should be used wholistically. I am willing to take on the task to draft it.

Sean: I see how some people would interpret the use of landmarks as optional if the relationship is available in text. I think it should be required but I can understand how people would interpret it as optional.

It is the "or are available in text"

<davidmacdonald> Proposed Failure "Ø "Failure of 1.3.1 due to regions of a page which are visually distinct​ ​AND which ​contain distinct groups of content (headers, footers, navigation bars, main content, asides) not being programmatically determinable or identified by text."

<steverep> I have not drafted anything, but would be happy to co-author

Adam: Sean just made the comment about text. If its in the text, it doesn't need to be programatic. We're talking about situations where it is not available in text. There is a difference between style and content. Style presentation does not need to be programatically determined. Headers and footers are often stylistic. I agree its important and it should be in the extension, but WCAG 2.0 doesn't mandate it. Prior to landmarks, this wasn't discused.

Andrew: Regarding Seans commnets. For 1.3.1 I think its either programatically determined or in text. Also, to note, WCAG isn't law. I think the chief concern was covered by Adam. For WCAG to require something it needed to require it when WCAG was generated. My recollecction is that we didn't require it when we wrote it. I feel like its something that we want but I'm concerned about a slippery slope where decisions at a future time.

<Zakim> steverep, you wanted to argue that a repeated set of content across an entire website is not style, it is structure

It is something that we want to address at a future time.

Steve: I wanted to respond to the comment that headers and footers are stylistic. I don't believe something repeated throughout a site is stylistic. It then goes to structure.

David: I think Andrew brought up a good point. I think it needs to be established whether it was required or not when WCAG was created. The language of WCAG was intended to be something that wasn't tied to technology. The argument about hte success criteria not including specific technologies was to let them stay stable.

Second point: Did it fail back then or not? I would argue it did fail but we didn't call it out. A few years later we found a better way to handle this and measure it.

Marc: Echoing more of what Steve and David said. I wasn't talking about the styling. I think visually its easy to see what is the header and banner content even without alot of the styling. I can perceive where things are on the page and I think it should be programatically determined as well.

Adam: I would like to discuss specific examples. If we're talking about a table of contents where there is a standard convention that the location dictates that it is a site map. That is a visual convention where it wouldn't be marked up with a header or landmark.

<davidmacdonald> https://github.com/w3c/wcag/issues/173

Patrick: Its dangerous to say we explicitly require certain stuffs becuase we are saying there are hard pass and fail situations. It risks situations such as where there is a header or footer but doesn't contain meaningful content failing. The challenge is without a hard pass/fail it becomes difficult to specify "meaningful content"

<adam_solomon> i meant that in such a case of a toc located in a specific location which everyone knew meant it was a sitemap then actually that would be a situation where you might in fact need a landmark or header

<Zakim> steverep, you wanted to give an opinion on always required and how to adjust the SC

David: We have experts that often evaluate meaningful content. Header content is often important.

<patrick_h_lauke> for repeated content we already have 2.4.1 no?

Steve: I don't think this always needs to be marked up. I can think of webpages that this would be meaningless. I think what needs to be focused on is when having programatc determinations that tell when entering and existing and allow jumping around. Repeated content is an example. I need to be able to skip it. That is what we need to target. Some web pages don't need this. The hard part is coming up with generic content to let the user navigate the page.

Adam: By adding this language we are potentially invalidating a lot of websites.

<patrick_h_lauke> generally: structure for the page needs to be conveyed IF by not conveying it a real-world user will not be able to understand it

<patrick_h_lauke> imho anyway

Andrew: Responding to Steve, when you talk about examples of pages where this isn't needed, it would be helpful but it sounds like you are talking about repeated content and we do have a success criteria for that (2.4.1). I think the internet is in general not compliant as this. I'm worried about taking pages that have been regarded as accessible for a while nad making them not accessible.

<patrick_h_lauke> rather than making the determination based on "is it styled differently? does it look like a header bar/footer bar?" etc, the guiding principle needs to be if it contains significant content, and whether NOT grouping and identifying that part of the page as a discrete section/entity will cause problems to users who can't visually perceive it

Its a difficult thing to do and it opens a door to what I was discussing before. If we have sometihng looks like tabs, do we need to mark it as a tab system or is it good enough in WCAG 2 that it is a list of links. WCAG was never about making it as easy as possible but rather adding a level of accessibility that was not available at the time.

David: The decision is hard. I don't want to whitewash over that. I think we have a pathway that we can justify. That is important. We are free to make this decision by documenting this as a failure technique.

<Zakim> AWK, you wanted to ask David if when the tab role is agreed on by the people in the group will that make it required by WCAG 2.0?

What is our role? Unlike tabbed interfaces, this is settled technology in the community, with screenreaders and experts. Some people might argue that you have ot have landmarks and html but overall the arguments are settled. Our mandate is to help people with disabilities. Tihs isn't a small win, its a big win. And its a big win compared to the effort to fix it.

Andrew: My question back to you is when the tab order is agreed to and settled, does that mean that WCAG 2 requires that?

David: My argument was not that we agree on it, but that everyone agrees on it. There will be disagreement on the other roles for a long time.

<davidmacdonald> language of the failure

<davidmacdonald> Content that is not distinct visually is not a failure

<davidmacdonald> Content that is not distinct in substance is not a failure

<davidmacdonald> Content that only has one or two items is not a failure because it is not a region (group of cohesive content). For instance, a footer with only a copyright notice, or a header with only a logo are not examples of regions because neither of these would be a group of content.

<davidmacdonald> https://github.com/w3c/wcag/issues/173

Alastair: Regarding what David said, we agree on landmarks when we agree that the page content needs it. I think we need to go back to describing when is a situation when a landmark is needed and when it is not. Making hard pass/ fail requirements will be hard when it hits the real world.

Correction, previous speaker was Patrick; Alistar: Third test is whether the landmark is useful. In the tab example, when a tab is changing the page, then a programatic relationship needs to be dictated. My gut reaction to the tab example was yes.

James: If its a tab, then it is required. If it acts like a tab and looks like a tab, then it needs to be a tab.

<JF> +1 to "Easy to do" - it isn't

Need to stop saying "easy to do" it may be easy for a single page but its not necessarily easy. That is not a vaild argument. Also, there are often pages where the main content follows the H1. Isnt' everything before the H1 a header?

Joshue: I have reservations about forcing a pattern. My concerns come down to usefulness in the real world. I'm not sure we can mandate that developers do something that may be harmful. Footers are pullof stuff that people don't read.

<Zakim> AWK, you wanted to ask how to reconcile this with 2.4.10

<patrick_h_lauke> apologies, need to drop out now.

JF: My concern is the failure procedure itself. The failure itself specifies a technique (Landmark regions, etc). You are referencing technology that was not available. I'd rather we create a new criteria for 2.1. I would rather not go back and change WCAG 2.0.

AWK: I have concerns about 2.4.10. It seems to be expanding the criteria. I have some concerns.

<davidmacdonald> https://github.com/w3c/wcag/issues/173

David: There is a discussion about 2.4.10. I encourage people to look at that. see link. In 2.4.10 we were talking about if you have an essay, include section headers. I don't expect much confusion about that. John, before you got on the call, my point was that with speed limits, the police don't always enforce it. But they can.

JF: Debate argument. Challenge is that it is retroactive. Not disagreeing that we should go forward with this. Lets put it in 2.1 AA. To try to be retroactive, its not easy. Its not trivial for tons of legacy content.

Steve: My position is that I understand the historicy and as generic as WCAG 2.0 was intended to be written, it still does. It has to be written in the mindset of the year it was written. I don't think there should be failure for a webpage that doesn't use landmarks. Looking at the language of 1.3.1, I see ambiguity that needs to be addressed. We talk about skip links when that is the way to jump around. There is ambiguity there. How much content requir[CUT]

link. Part needs to be addressed as a WCAG.next but there will just have to be ambiguity.

<JF> +1 - it's not the chqange that takes time, it's the regression testing

David: I appreciate the comment about legacy content. I'm expecting that in most of your reports you've been recommending landmarks. I've never had an argument about landmarks. (Discussion about difficult of making a change) We've had to discuss these debates throughout the WCAG process. For the group to determine. I've presented my argument as succinctly as I can.

I encourage you to read the language.

Adam: What James was saying, we need to consider the commercial ramifications but if we did decide this was within WCAG 2, we can't say that we won't enfoce it just because of the commercial impact. The key question is, is this included in 1.3.1?

JF: I'm looking through the minutes. I think the point James was making: Its not just the change but its also all the regression testing around it. I'm going to support this in WCAG 2.1 but will stand strong against this as a retroactive.

Kim: We haven't addressed usabilty. We have very dense sites and we have screenreader users who dislike the ARIA becuase its extra information. I don't think the way forward is clear as evidenced by discussion.


We've discussed this for 45 minutes but we don't have consensus. We recognize that this is valuable but do not have consensus on doing this retroactively.

<SarahHorton> Also no consensus about what qualifies as a section

<JF> I would like to propose that we seek to create a new Success Criteria that addresses landmarks/regions - perhaps a (??)

Point was to discuss this and air it. If we can't come to agreement that 1.3.1 requires this, we can't accept the failure. This is why failures are difficult to bring in. Seems working group can't come to agreement.

<davidmacdonald> but not html5 sectin

<davidmacdonald> +1

<Sarah_Swierenga> +1

We have a section on landmarks. We want to consider it for WCAG 2.1. Can we as a group resolve that this needs to be a part of WCAG 2.1?


<KimD> +1 to adding to WCAG 2.1

<alastairc> +1

<laura> +

<JF> +1 to adding this to a WCAG 2.1

<Makoto> +1

<laura> +1

<Lauriat> +1

<marcjohlic> +1

<Kathy> +1

<Joshue_10> +1

<Greg> +1

<steverep> Would ther be support for a failure on the underuse of landmarks in 2.0?

This has been a very interesting discussion. Thank you to David for spearheading this discussion. It will ultimately be very very valuable.

AWK: Item 10 is about what we need to think about for 2.1. We have a requirements document for the extensions. I'm just introducing this. Would a couple people look at these and see if these make sense if they relate to 2.1?
... The working groups have requirements as well. What are the boundaries that we are allowed to work with here? Making sure the extensions don't conflict with each other won't conflict. We won't have time to talk about this today.

JF: Earlier I referenced the possibility of creating a Would it make sense to make a 4th level? When we start digging into specific technologies, a fourth level may provide a way to handle specific technology. Food for thought.

Michael: Initial response. I think its worth talking about butI think for 2.1 we should stick as close as possible to structure of 2.0. I'd rather split 1.3.1 than create a 4th level. However, I think the benefits would make it worth talking about for 3.0. Again, initial reaction.

Andrew: I would say that for 2.1 it makes sense to keep it familiar but that argument could go either way (for or splitting 1.3.1)

Its a good pont but I don't know what the answer is.

JF: I think its a worthy discussion to have.

Katy: Adding a level is an option, but I'm not sure its the best option. I think adding an additional level will make it more complicated. We need to strive to keep it as understandable as possible. Less complicated the better.

AWK: Homework. Please look at the extension requirements document and I will kick off a discussion on the list.

Issue 188 (https://github.com/w3c/wcag/pull/188/files?diff=split)

AWK: Issue discussed as part of earlier discussion about point sizes and what they mean. On the call, we agreed in principle. What is proposed has been well vetted. Needs to go through CFC process. This has not been specifically surveyed. We can't change it in WCAG standard but can edit the understanding documents.

<alastairc> Main change is to add: "The point size should be obtained from the user agent, or calculated based on font metrics as the user agent does when evaluating this success criterion. Point sizes are based on the CSS pt size as defined in _CSS3 Values_. The ratio between sizes in points and CSS pixels is 1pt = 1.333px, therefore 14pt and 18pt are equivalent to approximately 18.5px and 24px."

<SarahHorton> +1

<Sarah_Swierenga> +1


This is an update of the understanding documents.

<jamesn> https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20160317/G145

<Joshue_10> +1 to both

Discussion: Can we put the text in G145 as well? Information about the pixel size would be useful.

<alastairc> https://www.w3.org/TR/WCAG20-TECHS/G145.html

RESOLUTION: Accept pullrequest

Alastair will add it to G145 as well.

<Sarah_Swierenga> have a good week. bye

<SarahHorton> Thanks, bye!

<laura> bye

<AWK_> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. Accept pullrequest
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/05/24 16:31:34 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/?:/JF:/
Succeeded: s/full /pull/
Succeeded: s/full /pull/
Found Scribe: Rachael
Inferring ScribeNick: Rachael
Default Present: AWK, EricE, Kathy, Laura, jeanne, KimD, alastairc, JF, Joshue108, John_Kirkpwood, SarahH, Makoto, David_MacDonald, Mike_Elledge, John_Kirkwood, Greg_Lowney, kirkwood, MichaelC, Katie, Haritos-Shea, patrick_h_lauke, Elledge, MacDonald, Katie_Haritos-Shea, wayne, jon_avila, marcjohlic, Rachael, BM, Shawn, Lauriat, adam_solomon, Davidmacdonald, Shawn_Lauriat, [Steve, Repsher], JamesNurthen, Steve_Repsher, steverep, Sarah_Swierenga, Steve, Andrew
Present: AWK Kathy Laura jeanne KimD alastairc JF Joshue108 SarahH Makoto David_MacDonald Mike_Elledge Greg_Lowney kirkwood MichaelC Katie Haritos-Shea
Found Date: 24 May 2016
Guessing minutes URL: http://www.w3.org/2016/05/24-wai-wcag-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]