Accessibility Guidelines Working Group Teleconference

09 Apr 2019


alastairc, AWK, MarcJohlic, JakeAbma, Jennie, Rachael, mbgower, Chuck, bruce_bailey, Brooks, Laura, Detlev, Raf, SteveRepsher, david-macdonald
MarcJohlic, Rachael


<alastairc> present?


<MarcJohlic> scribe: MarcJohlic

<Chuck> present regrets

TPAC 2019

AC: Quick update on TPAC - Group expected to meet Sept 19-20. Silver TF will meet earlier in the week on Sept 16-17. Registration opens May 6th
... that's the expectation, but waiting for the confirmation.

2. Silver Naming Survey: https://www.w3.org/2002/09/wbs/35422/NamingSilver/

AC: Silver TF did some brainstorming and came up with a few names.

<alastairc> https://www.w3.org/2002/09/wbs/35422/NamingSilver/results

AC: Most likely names were picked for the survey

Digital Accessibility Guidelines

Accessibility Guidelines

Digital Inclusion Guidelines

Digital Inclusion Guidelines for Information Technology

<Detlev> just added my vote

AC: Digital Accessibility Guidelines and Accessibility Guidelines appeared to be the top vote getters in this survey

<Zakim> bruce_bailey, you wanted to suggest WCAG

BB: Suggested "World Creation Accessibility Guidelines" - can keep the WCAG acronym. A lot of brand recognition already in "WCAG".

AC: Any reasons given in TF for not wanting to continue w/ WCAG?

BB: Don't recall anything specifically, but there was some talk about coming up with new acronym - and maybe coming up with something new going forward.

AWK: (from survey) We should think carefully about jettisoning WCAG - tremendous amount of name recognition that will be hard to rebuild. Suggest "Web & Content Accessibility Guidelines"

<JakeAbma> +1 to "Web & Content Accessibility Guidelines"

CA: I know that digital is more broad, but also know that other groups have looked at content from this group to adopt - and if include the word "digital" it may not be as appealing to these groups and down the road

AC: A couple of "can't live with" votes - but no comments to the answers.

BN: Accessibility Guidelines was too wide - could get confused to be outside of digital

<Zakim> bruce_bailey, you wanted to mention that the ADA AG

BB: The Access Board board already uses Accessibility Guidelines and it is too broad (for this).

AC: Rachael and I thought that "inclusion" goes far beyond disabilities - could get pushback there.

<bruce_bailey> just fyi: www.access-board.gov/guidelines-and-standards/buildings-and-sites/about-the-ada-standards/background/adaag

<JakeAbma> '];[;[[Pok,l.kop;

<JakeAbma> ][;/

<alastairc> q/

<laura> +1 to AC’s rationale “inclusion” is too wide.

<JakeAbma> /me sorry, my daughter was pressing my blue tooth keyboard... :-)

AC: 4 cannot live with "Dig It"

<AWK> Web & Content, not Web Content &

<Rachael> +1 to maintaining the name if possible. World Content Accessibility Guidelines. Web and Content Accessibility Guidelines, etc.

+1 to keeping WCAG with new name for the acronym

LC: I like the idea of keeping "WCAG" but we should have it go beyond just "web" and "content"

AWK: Thought about that - it may be how we spin it as well. "These are the guidelines that you need to follow to ensure content is accessible" doesn't mean that it only applies to the content author.
... It seems with that slight name change we could also broaden the applicability.

<bruce_bailey> imho for "web and content accessiblity guidelines" that "web" covers UA and AT well enough

AC: Reasonable feedback for this - not changing the name tomorrow - there's time. It looks like we're headed toward keeping WCAG or something around AG DAG

RAF: What about DCAG - Digital Content Accessibility Guidelines - it might be more precise than just DAG

AC: We need to broaden beyond just content with Silver

<bruce_bailey> as i recall, during the silver brainstorm, "digital" was the best discriminating

BB: None of us really loved "digital" per se, but it seemed to be the best fit during the discussion

Review of WCAG 2.2 Process and Acceptance Criteria https://www.w3.org/2002/09/wbs/35422/wcag22process2/

<alastairc> https://www.w3.org/2002/09/wbs/35422/wcag22process2/results

AC: This is Week 2 of reviewing our WCAG 2.2 Process and Acceptance Criteria
... E.A said "Two week sprints is very short when people have a day job. But also the coga topics may be hard to achieve in the time as we have very few members used to writing SCs"

<alastairc> https://www.w3.org/WAI/GL/wiki/WCAG_2.2_working_process

AC: In Step 3 we're getting small groups together to work and in Step 4 is where the work is actually done by the small groups. Two week period. I got back to EA with that explanation and she seemed happy with that. We may need to flesh that out in the descriptions more
... looks like Lisa believed the two weeks will not be enough time
... Lisa also felt it was too easy to object - objections need to be publicly logged. Andrew and I agree. Surveys will go out and folks will have to state why they don't think something is ready.
... Lisa also stated that the next draft should not be released w/o addressing user needs adequately.

BN: Who decided what the list of potential 2.2 SCs are?

AC: We asked the chairs of the various Task Forces - the task forces worked to define new SCs and then submitted their work back to the chairs.
... We had discussions that started at TPAC and then several surveys around things that folks would want to put into a 2.2

<AWK> https://www.w3.org/2002/09/wbs/35422/WCAG_22_priorities/

AWK: Link to Prioritization survey to talk about how we do this - around who's deciding the priorities: the answer is you all are
... I don't think it's impossible for something additional to be added to this list, but I think it gets increasingly difficult the further we go here.
... I don't think we're under any illusion that we'll have 20 new SCs in 2.2. We'll use this survey and reuse it and reuse it as Sprints progress. As we hit walls on something we'll decide we can't finish it - others might be really easy. It will be up to the WG members.

AC: Jennifer had concerns around Sprints being too short depending on time commitment of participants. Perhaps longer sprints would help?
... The 2 weeks sprints would be around review - Week 1 reviewing and commenting on the SC - updates can be made that week. Week 2 - updates have been made - is it ready now? If the answer is "no" - is it just a few tweaks? If so, highly prioritize in backlog.. if more in-depth it goes further back in the queue in the backlog

<Jennie> Thanks. I agree, that based on the explanation 2 weeks sounds good.

<AWK> AWK: SC's may wind up needing a pair of sprints initially in many cases.

AC: I'm not sure that adding a 3rd week will help us in that - it's a matter of managing the backlog - which we could keep going back to in future sprints.

<laura> LVTF is having a survey this week regarding if the TF works on a Supplemental Guidance Document or 2.2: https://www.w3.org/2002/09/wbs/81151/wcag22orSupp/results

JD: Explanation makes sense - two weeks should be just fine.

AC: Lisa is not on the call, so I will try to get with her separately

<laura> no audio

AC: Taking a look at the Acceptance Criteria
... Glenda's comment around the "Observations" section and Levels

<Zakim> bruce_bailey, you wanted to volunteer to work the observation and table over a bit more

BB: Bruce can take a stab at updating the table in the Observations section.

<AWK> AWK: Recommends moving the Success Criteria Acceptance Criteria to a page on its own (or moving the other content)

AC: Agree that "Further discussions" and "Observations" could be moved off to another page.
... Mike Gower had suggestions around Step 2 to remove "any" and add "fully" to read " .. tools required to fully test it ... "
... I agree with that change

<AWK> AWK: I think that an extension of an existing SC is creating new requirements

AC: Mike also had a comment around Step 8 that will tie in with Lisa's comment so we'll get to that one in a minute.
... Rachael had a comment - "I would like a discussion about editing existing SC. I believe we should be able to edit SC as long as the newly revised SC, if passed, will still allow the original SC to be passed. I believe we need this in order to avoid adding more and more SC."
... Some arguments against in the past, testing the waters in editing 4.1.1. now

AWK: In maintaining backward compatibility we didn't change wording of existing SCs in 2.1
... Argument around parsing is that a11y issues around parsing are covered by other SCs
... there's another one that we're looking at because sRGB is out of date now, so would be worth making that change
... another one there is a discussion about "at least" vs "at most"
... if the change doesn't have substantial impact on backward compatibility it's an easier case to make.

RM: In COGA discussion around how expanding the scope of 3.3.4 would be better than adding in a new AA SC

<Zakim> bruce_bailey, you wanted to agree with an editorial-but-normative pass

BB: Agree that we ought to be doing some light-touch, but normative changes to 2.0. In addition to 2.2 and Silver we should be working on a version where we can normative changes to 2.0 that keep the spirit of everything we have up to 2.2

<bruce_bailey> version would be WCAG 2.5 or WCAG 2.9

AC: Regarding EA's comment - again if we remove the Observations section from this page will help to keep it focused.
... Lisa has longer comment
... we shouldn't require a higher standard for test than we do for 2.0
... Believe it's a case of making something explicit - I'll have to reply to that.
... Lisa - "When a Sc is removed a new one SHULL be created to adress the user need!"

AWK: I don't think this is a problem that is going to come up.

AC: I don't think so either
... Lisa's comment around removing the bit around a new SC being added when criteria are met

AWK: I think this is one of the most important section. There will always be some that don't make the cut. If WG finds something is a good idea, but there's just some reason that it didn't get in (time, resource etc) - they would be prime candidates for a later x.x version

AC: Lisa's next point around testing that require large manual efforts - around tooling and tooling may not be ready at the time of CR
... That could cause issues for people that do need to adopt right away - will need to test - and would need tooling. Any SC that needs tooling like that should maybe be prioritized

(sorry - scribe lost context along the way in the list of comments)

AC: Brooks comments - "I think that an SC should only be allowed to be included in the Editor's draft when an SC is proven to be "implementable," but also "providing significant benefit to users with disabilities." In other words, I think there needs to be some sort of requirement that when a new SC is met, it will actually yield an immediate user benefit that significantly bridges gaps to access that where there before the SC was created."

<AWK> "Address a situation where a user with a disability will be disproportionately disadvantaged" = "providing significant benefit to users with disabilities."?

AC: Did you mean implementation from Web point of view ?

BN: I need to take another look at that

AC: Jennifer agreed with Rachael about being able to edit SCs as long as they allow for backward compatibility

<AWK> Brooks, see my comment /question a few lines up

<Rachael> scribe: Rachael

Alastairc: Any final comments or questions on acceptance criteria?
... we've dealt with most comments once we move the observation section

<AWK> https://www.w3.org/2002/09/wbs/35422/SC_Acceptance_template/

AWK: Related survey, link above.
... go through 1+ sprints for a proposal. This survey would be a template to evaluate and record approvals and concerns for individual criteria. It maps to these acceptance criteria.
... it asks all the different pieces to allow us to keep tabs on items in progress. I think this will help keep a running log of where one of these proposals is at and what concerns have been raised.
... and hopefully which concerns have been addressed.
... This is the 2nd part of Mike G's comments regarding a mechanism to keep tabs on this.

Review of QRG changes

Alastairc: I think it addresses some of the points Lisa and Brooks made. Any other comments?
... The education and outreach group made an update to the quick reference guide.

<AWK> https://www.w3.org/WAI/WCAG21/quickref/

<alastairc> https://github.com/w3c/wai-wcag-quickref/commit/97948777d75b0808b08dee2b5063fe87bf06284b#diff-8e1e66eea468af5201f5830e8cafd304

alastairc: I think the next change is to add tags. The changes are additions of categories.
... we should see them added to the quick reference.
... there is no particular action needed but if you are interested in their categorization, take a look.
... next step is getting techniques into the quick reference. Any questions or comments?

Issues survey https://www.w3.org/2002/09/wbs/35422/MiscItems04022019/

alastairc: Issue survey. This has been going a while.

New Technique for Device Motion Actuation

<AWK> After this can I recommend accepting any unanimous items?

alastairc: michaelG thinks it needs more discussion. Can we have two techniques with an "and" between them? This feels like 2 separate requirements.

Mbgower: There are two techniques. They are quite different. Two integrally related techniques but they are separate. To meet the SC you have to do this and that.

alastairc: I had a similar comment.
... some technical difficulties with the example.
... the shake to undo confused me because it can be turned off at the OS level, why would we need it as part of the technique.

AWK: The motion is disruptive so it needs to be turned off but the motion is needed.

alastairc: Can we find a different example?

Rachael: The handshake example was the only option found during the SC creation that wasn't a client application. Suggestions for additional examples are welcome.

Detlev: I'm not sure whether the site will be up or if it is up. Its a 360 degree turnaround scene. It shows a landscape and as you move it shows the landscape. You can only get to the links when you turn the camera and phone.
... I also have not seen many examples.

alastairc: This will be unresolved. We need some suggested examples and to find the first example. In terms of splitting it into two, would that make it easier?

One can focus on buttons and one can focus on motion actuation.

Rachael: Since this used to be two and was combined due to conversation, are we happy with this being two?

RESOLUTION: Leave open.

alastairc: AWK suggested closing all resolutions that are unanimous: 660, 671, 652, 678

AWK: 638 is also though Bruce noted he wants to talk about glossary going forward which we can do but doesn't relate to this particular item.

alastairc: Any comments, questions or objections before resolving 638, 652, 660, 671, and 678?

Issues resolutions

RESOLUTION: Accept issues 638, 652, 660, 671, and 678 as unanimous.

New Techniques for Label in Name

alastairc: Pair of proposals A & B. Some people accepted, 3 wanted changes, 1 needs more discussion.

Mbgower: I incorporated all the comments that were in prior to 30 minutes before the meeting started.
... The example I've done is exactly the same as the one used in another technique. I want to tackle title. Its part of the accessible name definition. Because we already gave the telephone label as the name for the first input. It becomes an aria described value for the first one and the accessible name for the others. The screenreader gets all the information. And with the use of title, it also adds value to anyone who is using a pointer.
... just using aria-label doesn't give you that. You have to hard code it and you lose the elegance of the screen reader handling and the pointer value.

You are enhancing with code but your not adding value.

alastairc: If its replicating an example from another technique, we would be going backwards. Can you live with this AWK?

AWK: Yes. I'm trying to catch up with updated technique. I think so.

Mbgower: The second bullet was on matrix. On a survey you get a matrix of inputs. For the users, they get the row header and then they rate each item in the matrix by the criteria. Programatically its a set of radio button groups.

<alastairc> radio button example: https://htmlpreview.github.io/?https://raw.githubusercontent.com/w3c/wcag/da4d2d1969e2335c90a2a419fd1075277fc5d143/working-examples/label-in-name-general/example5.html

Mbgower: normally you'd develop this as a stacked radio button groups. For an end user who identifies by speech, they interact with this in the same way they interact with a table. They interact with the row. AWK's point is valid programatically.

It is a radio button set but I really do think in this scenario from the user point of view, they are going to interact by the row label.

AWK: Michael, what happens if instead of using ARIA features. The challenge is that we get into a slippery slope of what counts as a label and what doesn't? It feels very clean to say the label for the radio button in the first column in satisfied.

mbgower: Is anyone who regularly uses dragon or speech operation on the call?
... I can walk through a few scenarios about how dragon uses it. If someone catcatonate the row and column headers on these, it won't fail.
... The DNS would label every possible input. It may redirect to the first one. it may not concatenate. Later on it should go to the selected input.
... one thing getting back to title, I really think that implementing this with a catcatenated title is a good thing. You can easily lose what row and column you are associated with.
... when you hover over the radio button, you get the entire value of the radio button which is very useful in a high magnification situation.

Brooks: A couple of issues. With the SC, it talks about labels. User interface components that include labels. Does something that pops up on hover, is that a label?
... I don't know if that's the label. Part of the issue is that a label persistently provides information about the page element that is not dependent on interaction.

mbgower: This isn't using the title as a label. We are making sure the visible label is included in the accessible name. The title being added is the visible row and column header.

<alastairc> Work phone example: https://htmlpreview.github.io/?https://raw.githubusercontent.com/w3c/wcag/da4d2d1969e2335c90a2a419fd1075277fc5d143/working-examples/label-in-name-general/example3.html

mbgower: In the telephone, the label work phone must be associated with an input for this to work. The group label which works with AT, isn't a part of the accessible name. You have to link "work phone" with an input and logic dictates its the first one.
... or you have to concatenate it with all three. You have to give them some kind of accessible name and that is where the debate over aria or title comes in.

Brooks: I'm thinking about situations such as unlabeled icons where there is no affordance. By adding title, is that the label we'd have to put into the accessible name?

mbgower: My previous understanding is that title is not a visible name.

Brooks: Agree.

mbgower: Does everyone on the call agree that the title attribute is not considered a label.

+1 to title attribute not being a visible label

AWK: I agree.

<laura> agree. title attribute not being a visible label

Alastairc: also agree.

<bruce_bailey> +1 that title is not label

<Zakim> AWK, you wanted to say that the verbosity is controllable by the AT

AWK: I wouldn't consider concatenating the two pieces of information. I wouldn't want to put something that would be announced with every item. The AT have verbosity settings which allow the level of detail they hear. I would argue for treating this from the developer's perspective because it allows AT to do something useful with it instead of preventing them from doing so.

mbgower: You recommendation is to use the column header as the label of the button?

AWK: Yes

mbgower: I think most speech input users would listen to the question and then move on becuase most users will listen to the row header not the column header as the label.

AWK: I would like more data on that. It feels awkward to say that WCAG recommends if your radio button is vertically oriented do this but if its horizontally oriented, do that.

If we are unsure we may be better off not saying that. I also appreciate all the hard work you've done on this.

mbgower: What level of data would people find persuasive? 10 users' input?

<Jennie> I need to drop off the call - thank you.

alastairc: It would depend on how consistent the results are. If you put it in front of 5 user and got a consistent result, I would find that as a persuasive usability test.

AWK: Does that mean this is a poor design pattern or should we adjust our guidance for patterns that follow a certain pattern?

mbgower: I've seen this done where this isn't radio button groups. It looks the same. They don't think about it as a radio button group.

<bruce_bailey> four or five experienced screen reader user giving you all the same answer would be persuasive to me

Look at the visual example such as the checkbox grouping. People see that and see the label. When you get into the matrix mode, people aren't dealing with a radio button grouping...they are dealing with a matrix. Its a rich component and from a label perspective for a speech perspective, this is the best way to use it.

detlev: select the options corresponding to the words. Why would anyone do that instead of saying the number?

mbgower: You can say select radio button but in normal functions you'd usually zero in a bit more. I think It does reposition to the top of the input - I will double check that.

detlev: As a speech input user, how would you select the second option?

mbgower: you'd say press tab.

alastairc: All questions seem to be around the more complex matrix and radio response. The ones with more inputs than labels.

mbgower: As far as I know those are the only ones. There is another question that is yours.

alastairc: did you address Bruce's comments?

mbgower: Yes.

alastairc: Can it be separated into two?

mbgower: I think it can perhaps even more. If you'd like me to make a version without the complex stuff, I can do that but these patterns exist in the wild.

alastairc: I think most of this is easy. I don't want to lose the more complex options but perhaps we can separate them. It feels like there is a dividing line.

mbgower: I can make a 3rd technique for the complex items. We could make it advisory.

alastairc: I think we can approve the simpler one and continue with the more complex one.

mbgower: to address AWK's process comment, I added to #1
... I did want to flag that I see a lot of inconsistency in how we structure our procedures. We should have someone QA across techniques.

alastairc: I will take that up with AWK.

RESOLUTION: separate techniques

trackbot end meeting

Summary of Action Items

Summary of Resolutions

  1. Leave open.
  2. Accept issues 638, 652, 660, 671, and 678 as unanimous.
  3. separate techniques
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/04/09 17:00:59 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/new AAA SC/new AA SC/
Default Present: alastairc, AWK, MarcJohlic, JakeAbma, Jennie, Rachael, mbgower, Chuck, bruce_bailey, Brooks, Laura, Detlev, Raf, SteveRepsher, david-macdonald
Present: alastairc AWK MarcJohlic JakeAbma Jennie Rachael mbgower Chuck bruce_bailey Brooks Laura Detlev Raf SteveRepsher david-macdonald
Regrets: BruceB
Found Scribe: MarcJohlic
Inferring ScribeNick: MarcJohlic
Found Scribe: Rachael
Inferring ScribeNick: Rachael
Scribes: MarcJohlic, Rachael
ScribeNicks: MarcJohlic, Rachael
Found Date: 09 Apr 2019
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)

[End of scribe.perl diagnostic output]