RE:WCAG 2.x maintenece

(Re-naming the thread and dropping Silver from CC as I’m going to focus on 2.x maintenance.)

Hi Jake,

Firstly, this is a good discussion to have, it bugs me as well.

There are a couple of things in progress that should help address several of the points in the article:

  1.  The re-design work that Hidde has been doing on the informative docs that makes clearer whether something is the most recent version, and generally improves the readability.
  2.  Getting some canonical URL meta-data into the old docs, pointing to the newer ones. That should reduce the old docs turning up in search engines.

Prioritisation:
It is generally me that sweeps 2.x github issues and pulls them into surveys, my current prioritisation is:


  1.  Things which have deadlines. Currently that’s WCAG 2.2, so anything pertaining to normative updates it top priority, followed by informative docs to support that.

  2.  Issues which have a clear outcome / PR. It takes so long to sweep the issues, I rarely have time to work on the issues. Therefore anything that has a clear outcome (either a draft response or PR) is what can be pulled into a survey for review.
Within that, I try to pull together topically associated things, e.g. by Success Criteria. It is difficult to skip back and forth between different guidelines/topics, so I try to minimise that, although it isn’t always possible.

  3.  Things with multiple issues. If I can put several issues together (duplicates, or at least multiple things resolved by one change), that has a higher progress value.

People have probably noticed Patrick’s name turns up a lot in the surveys, which is primarily because he creates PRs to address the issues. (He’s not the only one, but the most prolific for 2.0/2.1 issues.)

Within the range of issues on github, I do wonder how many are things we really need to deal with?  We used to use the email list (or the interest group email list) to discuss “does this thing pass/fail?”, or “what does this mean?”, but now people generally open an issue.

For example, there are 64 issues I’ve marked as ‘discussion<https://github.com/w3c/wcag/issues?q=is%3Aissue+is%3Aopen+label%3ADiscussion>’ because I don’t expect them to resolve into a change to the documentation. Could we just close those? (Particularly if they come from members of the group.) We have a process to go through, but could we create a short-cut for that type of issue?

There is another category of issues which I would describe as: Things which someone has spotted in the docs that may not be completely logical, but probably never (or very rarely) come up in real life. E.g. When someone runs training and takes the approach of explaining the guidelines, people new to them focus on one aspect and ask questions. That’s fine, but if we try and solve every logical issue across every web-dev scenario it is a never-ending tasks. We need to prioritise.

(Sidenote: I run a lot of training but I rarely get those sort of questions. I think it’s because I start each point with the user-need and the best way to solve it, rather than starting with exactly how you meet the SCs.)

We need to consider that if we try and explain every scenario and show lots of (code) examples, the docs get longer and it is more likely that we create conflicts in the documentation, which again makes it harder to maintain. There is probably a rule similar to “as simple as possible but no simpler”, e.g. “as concise as possible but not overly concise”.

Another issue is that no-one knows everything about every SC. I don’t think that’s due to our docs, it is just that accessibility (combined with design & web-dev) is an incredibly wide subject. Therefore when someone focuses on one aspect of one SC, it is easy to miss how it interacts with other SCs. Those “simple fixes” may not be as simple as they appear when you are focused on one bit.

Another consideration is that many of the techniques do appear dated, and they aren’t what we would consider best practice. However, they are still valid techniques. I’m not sure how (or whether) we can solve the problem of “developers just google it and copy the first code they find”, apart from removing code examples?!

That’s how I think of the problems, and I don’t have all the answers. For me, the main things we need solutions for are:

  *   How to prioritize the WCAG 2.0 / 2.1 issues, and how to de-prioritise some.
  *   How to encourage more people in the group to propose resolutions to the issues.

Kind regards,

-Alastair

PS. On a more technical note, it would help to have a more 1:1 mapping from issues to PRs. For example, Jake raised about 8 issues on 3.3.3 recently, all resolved by 1 PR. We either need to have 1 issue that is grouped together (which looks better from my point of view), or a PR per issue. Otherwise, when we survey it and 6 of 8 things are accepted, you then have to pick apart the PR.



From: jake abma

Hey all,

Based on my comment / question from yesterday and the Chair meeting for today I would just like to send you all a blog post from Rian where she summarizes concerns I've heard a lot last year from many different people.

https://level-level.com/blog/we-need-to-talk-about-wcag/


We all want to create awesome guidelines with brilliant explanations and work hard to provide these, but sometimes it is very, very, good to reflect on what we do and where possible ask the hard questions if we are on the right track.

Personally I do not have the perfect answer, but it would be great to have a thorough discussion about the critical notes from the community.
It might be that we can do more than only wait a couple of years till SIlver might be mature enough to use, and IF Silver solves the critical notes!

Starting with all Github issues, fixing what we know is broke, might be a good starting point, next to maybe really thinking on what we would like to achieve in the "short term" with WCAG 2.3 (?) (if we go that way)

For me it feels like the WCAG WG and all related sub-groups are exponentially growing (too ?!) fast and this might result in even more cluttered documentation and it is very hard to keep track on things.

Don't shoot the messenger ... :-) Love you all, and hope this positive critical note helps us steer into the good direction!

Cheers,
Jake

Op di 18 mei 2021 om 19:11 schreef Christopher Loiselle <chris.loiselle@oracle.com<mailto:chris.loiselle@oracle.com>>:
Hi All,

Here are the minutes from today’s meeting: https://www.w3.org/2021/05/18-ag-minutes.html


Thank you,
Chris

From: Chuck Adams <charles.adams@oracle.com<mailto:charles.adams@oracle.com>>
Sent: Monday, May 17, 2021 3:39 PM
To: Chuck Adams <charles.adams@oracle.com<mailto:charles.adams@oracle.com>>; WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>; Silver TF <public-silver@w3.org<mailto:public-silver@w3.org>>
Subject: [External] : UPDATED AGENDA and Survey - AGWG & Silver joint Meeting May 18th 2021

Apologies for the late notice, our agenda is being updated.  WCAG 3.0 Headings review will be moved to the following AGWG meeting (5/24/2021), and will be replaced by:
               New Errors Guideline https://raw.githack.com/w3c/silver/srayos/error-prev-index-2/guidelines/index.html#error-prevention<https://urldefense.com/v3/__https:/raw.githack.com/w3c/silver/srayos/error-prev-index-2/guidelines/index.html*error-prevention__;Iw!!GqivPVa7Brio!MxO1FHxjJilBFgTRgDfK0InZrEA5g1kJb1d6GrHFAsFMnostrxpICymnGHVUFzO1e90$>

We will extend the headings review survey by one week as well.

Regards,
Charles Adams

From: Chuck Adams <charles.adams@oracle.com<mailto:charles.adams@oracle.com>>
Sent: Thursday, May 13, 2021 1:57 PM
To: WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>; Silver TF <public-silver@w3.org<mailto:public-silver@w3.org>>
Subject: [External] : AGENDA and Survey - AGWG & Silver joint Meeting May 18th 2021


The AGWG and Silver TF will be meeting on Tuesday, 18th May  2021 at 11.00 AM Eastern US (Length: up to 2 hours).



Agenda
•         TPAC is Oct 2021, breakout sessions? https://www.w3.org/wiki/TPAC/2021/GroupMeetings<https://urldefense.com/v3/__https:/www.w3.org/wiki/TPAC/2021/GroupMeetings__;!!GqivPVa7Brio!IWuYJbhCkOUZXAAZVjB5-MBRqROq0n0hMW9ZdAzETPhdW8WUM4XwTaW-Klm5i5-75g$> (5-10 min)
•         WCAG 3.0 Explainer survey https://www.w3.org/2002/09/wbs/35422/WCAG30-Explainer/<https://urldefense.com/v3/__https:/www.w3.org/2002/09/wbs/35422/WCAG30-Explainer/__;!!GqivPVa7Brio!IWuYJbhCkOUZXAAZVjB5-MBRqROq0n0hMW9ZdAzETPhdW8WUM4XwTaW-KlnjqVocZA$> (20min)
•         WCAG 3.0 Headings review https://www.w3.org/2002/09/wbs/35422/wcag3-method-headings-exercise/<https://urldefense.com/v3/__https:/www.w3.org/2002/09/wbs/35422/wcag3-method-headings-exercise/__;!!GqivPVa7Brio!IWuYJbhCkOUZXAAZVjB5-MBRqROq0n0hMW9ZdAzETPhdW8WUM4XwTaW-Klle846ppg$> (50 min)
•         Introduce the new group homepage (5 min)
•         WCAG 2.x issue resolutions (Q1-4) https://www.w3.org/2002/09/wbs/35422/WCAG22-Misc-items/<https://urldefense.com/v3/__https:/www.w3.org/2002/09/wbs/35422/WCAG22-Misc-items/__;!!GqivPVa7Brio!IWuYJbhCkOUZXAAZVjB5-MBRqROq0n0hMW9ZdAzETPhdW8WUM4XwTaW-Klnwfr4q2w$> (30 min)
Please reply with regrets to group-ag-chairs@w3.org<mailto:group-ag-chairs@w3.org> (only) if you would normally attend this meeting.



To connect to the meeting:

Meeting call-in and zoom information is at this non-public page: https://www.w3.org/2017/08/telecon-info_ag<https://urldefense.com/v3/__https:/www.w3.org/2017/08/telecon-info_ag__;!!GqivPVa7Brio!J0BzcfN-fvWzeuE8FRn1LYO8qvRTKYGnd37-cEbSBz_cqCFILzPZSAf2BIXen8QUMQ$>



IRC: http://irc.w3.org<https://urldefense.com/v3/__http:/irc.w3.org__;!!GqivPVa7Brio!J0BzcfN-fvWzeuE8FRn1LYO8qvRTKYGnd37-cEbSBz_cqCFILzPZSAf2BIW9ElQGRQ$> port: 6665 channel #ag

Scribe list: https://www.w3.org/WAI/GL/wiki/Scribe_List<https://urldefense.com/v3/__https:/www.w3.org/WAI/GL/wiki/Scribe_List__;!!GqivPVa7Brio!J0BzcfN-fvWzeuE8FRn1LYO8qvRTKYGnd37-cEbSBz_cqCFILzPZSAf2BIXhJb_iZg$>

Kind regards,
Charles Adams