Re: Advance WCAG 2.1 to Proposed Recommendation

Hi Kim, Brooks,

Thank you for putting your perspectives forward, I appreciate that your response was not an opposition to proceeding in spite of your concerns. I’d like to respond as I think there might be some things I can highlight that address your concerns (to some extent), and open up for ideas on improvement. Apologies if you are aware of some or all of this, they can be easy to miss in the avalanche of email & information.

Also, I’m sorry for the long email, the TL;DR version is: Here are some ways we tried to address those concerns in the current process, and we are very open to suggestions for improving that in future.



  *   First, there are a few SCs that I feel should be issued as “best practice” guidelines. The constraints of working within the 2.0 format caused some uncomfortable contortions, and excluded many valid and valuable recommendations from all task forces.

That is part of the overall plan. You might remember that we updated the introduction a few days ago to include a link to supplemental guidance.

That supplemental guidance (from COGA initially, hopefully from other TFs soon) will include the guidance that didn’t get into WCAG 2.1. Longer term this should be addressed in Silver, but it is a step in that direction during the interim.



  *   Second, I am uncomfortable that so few people attended the meetings and that things moved forward with a minority of voices being heard. Obviously this is a risk with voluntary attendance. However, I wonder if this could also be seen as lack of support?

This one is hard to quantify, partly because it can be difficult to know how many people are involved at any point, and partly because I’m not sure what ‘enough’ would be.

The AGWG regularly gets 15-20 attendees on the (traditional) Tuesday calls, no quite so many on the overflow-Thursday meeting or when there’s a holiday. Each of the 3 TFs has 5-8 regular members, few of whom also go to the AG calls so that’s mostly additional people with a particular focus. We did a lot to encourage asynchronous participation by mailing list discussion, wiki, github issues, pull requests, etc. For example, we’ve had 100s of comments from the public in several rounds of wide review.

I don’t know the figures on average but I suspect that is more than most W3C groups, and so it should be given the topic & scope.

We found it difficult to make some decisions and still relied on the calls a lot, but tried to accommodate time zones as much as possible. We also widely announced the work on WCAG 2.1 and invited participation. Ultimately, the work is the product of the people who showed up and we have to accept that.

We also have to recognise that participation often comes from seeing problems. I.e. certain people or organisations will be very vocal if they see problems, but if they don’t, they might not comment. Obviously we cannot be complacent and we are open to new ideas about getting more people involved. However, there have been lots of comments and issues from various places (e.g. 185 public-closed comments in github).



  *   There were fewer voices representing the viewpoint of authors/implementers, for whom there may be massive expense and unforeseen problems in implementing some of the SCs. The guidelines would benefit from increased participation by content authors so more viewpoints can be taken into account.

Although it may not be obvious, I think most of the participants work for implementors either directly or one step removed. For example, the company I work for is primarily UX research and web/app development. Most of people sitting near me are developers, we produce websites as well as testing them for accessibility. There are a few others who are from (relatively) small-scale production backgrounds.

I get the impression that the participants from larger companies are in close contact with their implementation teams and part of their role is to flag issues back to the AGWG. As you mentioned, because WCAG is used for policy & legal cases it is in their interest to prevent SCs creating implantation headaches.

Even people working for accessibility specific organisations generally do testing, consultancy and training for clients. Therefore they are only one-step removed from implementation issues, and several (I won’t name names) are not reluctant to raise those kind of issues! That is natural, you don’t want to be the bearer of bad news.

Again, I’m not saying we should be complacent and we would love to get more involvement from authors, I just think it is unfair to say that dev/design/author voices have been missing.



  *   Internationalization/globalization was under considered.

In the current process we tried to mitigate that with an internationalisation review of WCAG 2.1, which was conducted. Before that, we did approach Richard Ishida (well, I almost physically tackled him at TPAC) for particular SCs such as reflow and text-spacing.

It is still an issue that we can only incorporate input from people who contribute, and we didn't get as many non-native English participants as we hoped in spite of supporting asynchronous participation and reaching out in various ways. We now have a staff contact on board in China who will work on increasing outreach there for future work. We will likely also take more steps earlier in the process of subsequent work to solicit international participation and review.



  *   I am uncomfortable with a few aspects of the process, especially confusion over whether we had to demonstrate a clear and immediate benefits to users.

The benefit to users aspect was defined earlier in the process and came from the Task Forces. There was a long period of gathering research and getting the experts on particular issues involved and there is a huge amount of documentation about the user-requirements. [e.g. 1, 2, 3]

There was a ‘boil, simmer, reduce’ process of translating the requirements into SCs, so what we have left is a combination of what benefits users, what’s feasible, and what’s viable. David did a nice diagram of this [4].

If you’re referring to the SCs which also require support from user-agents (1.3.5, 1.3.6, 1.4.12) then as Josh mentioned on the call this has long been difficult. The user-agent guidelines have been de-scoped from the group’s charter, so there isn’t a clear process for those. However, we did set the bar at the same level as websites: two independent implementations.

People new to WCAG/ARIA might see landmarks as not having a clear and immediate benefit to users if they don’t have screenreader experience. If we haven’t used the tools it’s hard to see. Also, when WCAG 2.0 was released in 2008 I think it was difficult to show an immediate benefit for 4.1.2 without widespread UA support.
We do have to be careful about introducing technology via guidelines, but each of the A/AA criteria have widely available user-agent support.

I hope that goes someway to addressing your concerns, and if you have any suggestions for improvement please do reply, either on-list or to the chairs if you prefer.

Kind regards,

-Alastair

1] http://w3c.github.io/low-vision-a11y-tf/requirements.html <http://w3c.github.io/low-vision-a11y-tf/requirements.html%20%0d2>
2<http://w3c.github.io/low-vision-a11y-tf/requirements.html%20%0d2>] https://w3c.github.io/coga/user-research/

3] https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/New_WCAG_2.0_Techniques <https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/New_WCAG_2.0_Techniques%20%0d4>
4<https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/New_WCAG_2.0_Techniques%20%0d4>] http://www.davidmacd.com/blog/what-are-WCAG-success-criteria.html