<alastairc> present?
<AWK> +AWK
<MarcJohlic> scribe: MarcJohlic
<Chuck> present regrets
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.
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
<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.
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: 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?
alastairc: Issue survey. This has been going a while.
<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?
RESOLUTION: Accept issues 638, 652, 660, 671, and 678 as unanimous.
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
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]