Meeting minutes
Announcements
Update from AG WG on Tuesday. Went through all issues, pending approval this Tuesday, we got approval of all content. There were only a few comments.
On Tuesday a call for consensus (CfC) will go out for asking for publication.
Not sure what the impact is with the minor changes that we are discussing today - Mary Jo to discuss with Chuck & Daniel.
Publication may also be delayed - will probably be week after next (Tuesday June 4th)
bruce_bailey: WAI also hired a developer which should help.
mitch11: Is 1 of the Tuesdays also when the broad review happens?
maryjom: When we publish we then trigger the broad review
We need to complete the AG WG review on Tuesday 28th, then call for consensus, begin on Tuesday 25th, finish on Friday 28th
<bruce_bailey> Welcome to Kenneth Franqueiro
<bruce_bailey> Role: Web Software Engineer
<bruce_bailey> Ken joined W3C in May 2024 to work on improving infrastructure for surfaces related to the Web Accessibility Initiative (WAI).
Sam: As we are rehashing issues, should this be done in the public review part?
maryjom: Good point - want to get this done before full review, but there may come a point where it is good enough...
maryjom: We don't want to have lots of substantive changes after we go out for public review - as this will drive another public review
Chuck: At this time, our best considerations (easiest) are editorial. Any substantive change from this point forward are more challenging as they will extend the schedule
Chuck: Quoting Michael Cooper: "The perfect is the enemy of the good"
AG WG comments received thus far in the review issues
If we make substantive changes today, the AG WG review clock gets extended
(another 5 days)
AG WG comments received thus far... Nothing substantive. Most getting lots of thumbs up
There is a need for link to errata from 4.1.1 Parsing - will be a quick edit. Also a discussion from Shadi on accessible authentication. We will discuss this next today
One question from guidance for closed - on menu driven systems - does it include interactive voice systems? We said it was limited to page titles - so no need for change to definitions
Revisit discussion on 3.3.8 Accessible Authentication
<maryjom> Proposed changes: https://
Accessible authentication: proposed changes from last week
<maryjom> Survey results: https://
<maryjom> Last week’s discussion: https://
Invite Shadi to give input, then Bruce added comments.
<bruce_bailey> email to ag is here: https://
shadi: Don't want to hold the work up, but is an important issue
In reviewing accessible authentication in detail. It assumes there is a mechanism to copy/paste or use password managers (e.g. 2 factor authentication, copy password)
Lots of assumptions that you get over the need to remember things by copying/pasting to pass along information without having to remember it
That is not always the case in software. Makes sense for most apps, but we should also consider other contexts for software where password managers / copy/paste may not be feasible. In this case, you have to type in user / password
There are examples where we have touched on this (e.g. reflow).
Shadi proposes such a note, or add it to note 3 which already covers some scope limitations
shadi recommends doing this as a separate note as it is clearer
Chuck: (chair hat off) Thanks to Shadi for the input - very helpful. Chuck's understanding is that the SC just asks for not blocking these solutions - it is not advocating for these solutions, you just cannot prevent them if they exist.
shadi: Agree with you Chuck. But even if you do not actively block copy / paste, there are instances where it is not present (e.g. when OS is starting up). You are not blocking it, the system just doesn't have that function yet - it's not under the control of the author
maryjom: Agree - initial password / power on password
GreggVan: If what we mean that you should not block existing, then we should state that.
… We shouldn't say it applies as per... Instead we should say it doesn't apply to some systems. Maybe move it down into a closed functionality clause
mitch11: Chuck's comment might reduce the likelihood of Shadi's concern. If software is on the platform, and software does not actively block, then software has done its job. There are components of the platform that might have a user interface - and that might be more relevant. Has parallels with resize text - original WCAG was web centric,
assumed some things. For this one, if there are some cases it might not meet this criterion.
… mitch11: wonder if this applies to open software as well, or is Gregg correct and this is closed functionality only
Sam: We can't put not applicable, worried that we are making more changes
GreggVan: Password manager is a type of assistive technology. So you could argue it is a closed functionality (as system is not open to a password manager).
… Other point: we start by saying this applies. But it doesn't to all systems (e.g. TV).
… Closed functionality would solve the problem
Purpose of note is not to change what you have stated, it just explains what you stated
Chuck: Interpretation point. Sounds like are focused on password manager / copy & paste. This standard does not state that you must allow these features. The standard should allow for other mechanisms as well as cognitive tests. TV could apply, as long as you don't force the use of a cognitive test
Password manager is just one means to avoid cognitive tests - there are other means.
GreggVan: Password manager is the only solution for passwords
Now you require have a biological login at every login (e.g. hotel)
shadi: Not saying applies/doesn't apply. I think we have other requirements where we say there may be limitations (e.g. how much zoom the OS can do, so do as much as you can if it doesn't support 200%). Thinking something along these lines
… Mostly closed functionality, but there are some examples that might be open aspects. These are assumptions. Understanding document is pretty clear about what is being assumed regarding copy/paste
Sam: Thinking as a solution. We have other areas where we say 'it may not be possible to meet this criterion'. So use similar language
<Zakim> PhilDay, you wanted to say Biometrics is another way to authenticate
<shadi> +1 to sam
PhilDay: Alternatives to password: biometrics, personal tokens, wearables, QR code pushed to wearable or smartphone, etc.
<bruce_bailey> +1 to Sam, if we have phrasing attached to other SC which we might re-use for this SC
GreggVan: Adding biometrics to everything is not feasible right now
Proposed language: There are cases where applying this success criterion to non-web software for products with closed functionality is problematic: give example from Shadi's words...
GreggVan: Better to say the author shouldn't do anything to add a further cognitive test
<Zakim> PhilDay, you wanted to suggest language
<ChrisLoiselle> Do we have results of the survey available please?
<bruce_bailey> +1 to Phil's proposed language. That addresses the question I put in the Google Doc.
(From SC problematic for closed, 1.4.3)
mitch11: We are making an addition to something that hasn't been written yet. Let's not make too many assumptions about normative text
<Sam> +1 to MJ suggested text https://
mitch11: Convinced by this discussion that Shadi's concern is valid.
<Sam> +1
mitch11: But don't think we should get into discussions about reasonable accommodation for this type of SC
GreggVan: If we have other places where we say this is problematic, we should then say what is problematic, and what they should do about it. We have to for closed functionality as it's outside our remit. If we say you must apply, then we should not then say it is problematic.
maryjom: We already do this in 2013 version (problematic)
Sam: Feel like suggestion that Mary Jo has written (linked above to google doc) gets someway to address the problem. Put it in closed functionality section and leave it at that
maryjom (Added in as option 3 in google doc)
<Mike_Pluke> +1 to Mary Jo's Option 3 proposal.
GreggVan: Agree with Sam, except it needs to be in closed functionality (not add this note and put in closed). This note only applies in closed
<bruce_bailey> +1 to MJ suggested text
GreggVan: Put it in closed, it solves the problem...
mitch11: Mistaken that nothing had been written - was only looking at option 1. Think the reason we didn't have an exception in closed - as we thought that it could also apply to open systems.
<maryjom> In the closed functionality section we have: 3.3.8 Accessible Authentication (Minimum) — There are situations where meeting this success criterion is problematic:
<maryjom> Systems that are designed for shared use (such as in a public library) or have closed functionality might block mechanisms typically used to assist the user, such as copying authentication information from a password manager. Instead, an alternative authentication method might be needed, such as an identity card scanner.
<maryjom> Where standards for banking or security have authentication requirements that are regulated or strictly enforced, those requirements may be judged to take legal precedence over Success Criterion 3.3.8 Accessible Authentication (Minimum).
mitch11: Then becomes a question of closed to what
<Sam> how about the example of bios password at startup
mitch11: Don't think it is just closed, don't think we should just put in closed
shadi: First start is just 1 example, so it is better to start with 'there may be cases where it is not possible to ...'
<Zakim> Chuck, you wanted to say we (including me) are all repeating our points
[edits in google doc by various anonymous animals]
Chuck: Think we are going round in fun circles. Time to move on.
<shadi> +1 to latest proposal in Google doc
GreggVan: Go back to, we are talking about software. Thinking there are probably solutions.
… We do have a problem - we cannot say it applies to all software
<bruce_bailey> From live edit in Google Doc:
<bruce_bailey> NOTE 4: There are cases where it may not be possible for non-web software to meet this success criterion, for example on first start of the product, login may be required to start the installation process (using your profile).
Latest proposed note: Option 3: May not be possible to meet
NOTE 4: On first start of the product, login may be required to start the installation process (using your profile), and in such situations it may not be possible for non-web software to meet this success criterion.
GreggVan: Misses the point - a note should not change the original statement (that this always applies)
bruce_bailey: Got edit in the doc
ChrisLoiselle: Reading WCAG 2.2 understanding. Note - support for password managers, number 2 is copy/paste to reduce cognitive burden. Examples may or may not be contained by these 2 examples.
… If logging in, you may not have copy & paste, but you may have biometrics as an alternative
<Chuck> should we meet tomorrow?
maryjom: This is going to require some additional work outside the meeting, so should have a Friday meeting tomorrow to work it through
So put this on hold
Survey Results: Additional proposals for changes
<maryjom> https://
(1 of 3) Update definition of “closed functionality”
<maryjom> https://
Results. Mary Jo sharing screen
GreggVan: Edit covers Phil's concern. Agree with Loic's edit.
<Chuck> +1
<ChrisLoiselle> +1 to Sam.
Sam: Really concerned about changing the definition of closed functionality. We would then change all the notes that refer to closed. OK to clarify things, but if you change definition it has a big impact. We have hashed this through many times.
GreggVan: Believe that it is currently wrong, and this edit fixes it.
<Chuck> It's time. We should check to see if members must go
<Chuck> Can MJ remain on for a moment (for a non-private conversation)?
GreggVan: Maybe the solution is to go with Sam - maybe just add this as a note, instead of changing definition. Note: there are cases like smartphones where there is AT built into the platform
<bruce_bailey> +1 to Mike Pluke suggestion in survey.
<Sam> i can stay
<Mike_Pluke> What time?
PhilDay: Agree to not changing the definition. Would be more supportive of a new note instead of a change to a definition.