– DRAFT –
AGWG meeting

WCAG 3.0 First Public Working Draft Published https://www.w3.org/blog/2021/01/wcag-3-fpwd/

WCAG 3.0 First Public Working Draft Published

<Chuck_> https://www.w3.org/blog/2021/01/wcag-3-fpwd/

you can review it and we are open to comments

Editorial update to Silver Task Force Decision Policy https://github.com/w3c/wcag/pull/1601

congratulations, everyone.

<Rachael> old text: For decisions being considered in asynchronous communication tools, or decisions made during a meeting at which the participant was not present, objections must be raised within two business days of the call for objections.

<Rachael> new text: For decisions being considered in asynchronous communication tools, such as Calls for Consensus, objections must be raised by the deadline, which will be no shorter than 2 business days after the call for objections.

Survey for "Resources on Alternative Text for Images - Change in Redirected Link https://www.w3.org/2002/09/wbs/1/alt-update2021-01/

please participate in the survey and looking for the result by thursday.

WCAG 2.2 Redundant Entry https://www.w3.org/2002/09/wbs/35422/wcag22-redundant-entry-updates/

Question 1 - Redundant entry, term "step" is ambiguous #1345

chuck: Chuck is reading Gundula's comment

gundula: change is more confusing.

chuck: Chuck is reading Andrew's comment

<Fazio> -1

mikegower: there may be a specific reason for this.

<Chuck_> current proposed: For steps in a process, information previously entered by or provided to the user that is required on subsequent steps is either:

<Chuck_> AWK suggestion: Information previously entered by or provided to the user that is required to be entered again in the same process and in the same user session is either:

<Fazio> I say remove session

<alastairc> Seems ok to me, is there anyone here who remembers why step was there to start with?

mikegower: I reworded my PR and please read my last comment.
… I am fine for now.

sarah: if we leave step in as it is, it need some tweak, editing to the understadning document

alastairc: dont think a reason to remove the steps.

<Chuck_> ach Mic

the scope is kind of neat I am find with that change basically.

<Fazio> I agree its not restricted to page

mikegower: definition of process is not covering multiple pages. we need to make it more clear in understanding doc

faz: I suggest we can remove session but keep the step. step is very common, self sufficient language.

alastairc: regaridn Wilco's comment, step can be various sense of concept. ex: various input under accordion and so on

<michael> I agree. Steps doesn't seem needed. Can clarify in understand ing

<Fazio> good point Alastaair. It just seems to flow better with step

<Fazio> but not a hill for me

alastairc: as far as we keep the same process, the scope can be taken care of.

<Jemma> s/regardn/regarding

<kirkwood> think aliatari covered it as long as process is in there

<kirkwood> think we should keep step

<kirkwood> but can remove

comment summary: gundula- do not make change, andrew- change the concept of step

<alastairc> Suggest: Update the SC text as per AWK's, and update the understanding to make the 'step' aspect clear.

<Chuck_> AWK suggestion: Information previously entered by or provided to the user that is required to be entered again in the same process and in the same user session is either:

<JF> +0

<kirkwood> do we need to define prcess?

<michael> +1 remove step

<alastairc> process is already defined

<kirkwood> ok

jf: I am concerned that removing step and keeping process can be problematic in some cases.

<Fazio> that is the definition of process

<alastairc> Current: "Exception: When re-entering the information is essential. "

<Zakim> alastairc, you wanted to say process is defined, and we have an essetnail exception

mikegower: next PR will may help Jf's concern.

jf: process is vague.

conccept

<Rachael> From 2.2 glossary: process - series of user actions where each action is required in order to complete an activity

chuck: what is your standing, Jf?

<Zakim> Rachael, you wanted to ask where it is best to address the "not on the same page" point

jf: I prefer clear languge like Andrew's and leaning to Andrew's suggestion - removing ambuguity but add some ambguity for future

rachael: copied the meaning of "process" above. I am wondering whether we can add its definition to glossary.

jf: can or must?

rachael: can

<Rachael> example: Successful use of a series of Web pages on a shopping site requires users to view alternative products, prices and offers, select products, submit an order, provide shipping information and provide payment information.

<Rachael> I am fine with not tackling it and I will create an issue to discuss the definition.

<Chuck_> +1 michael

mikegower: this does not need to be tackled and I propose to add separate issue for the definition of "process"

chuck: agree that it can become distinctive issue.

<nicaise> +1

<Chuck_> AWK: Information previously entered by or provided to the user that is required to be entered again in the same process and in the same user session is either:

<Sukriti> +1 to Rachael also applicable to findable help and difference between 'process' and 'set of web pages'

sarah: wondering whether this part of proposal update understadning documentn or not

alastair: the change is limited to proposal for now.

<Fazio> 0

<GN015> +1 fully agree to removing 'step'

<michael> +1

<david-macdonald> +1/0

<Detlev> +1 remove step

<Sukriti> +1

<sarahhorton> +1

<Rachael> +1

<laura_> +1

<MelanieP> +1

<oliverkeim> +1

<jon_avila> +1

<JF> +1

Resolution: Update PR 1597 and update draft response to remove "step" to address issue #1345

Question 2 - Comment from IBM: Redundant Entry needs to be more tightly scoped in the SC language

issue 1410

we have mixed opinions for the issue 1420

Chuck is reading each opinions from the issue

gundula: change request does not match the response so I prefer to leave this to understanding doc.

mikegower: ?

faz: suggest to remove "sesssion"

<Fazio> I agree

<Fazio> sorry

alastairc: I was not certain which of two options proposed and I am fine with either. but I am was not sure what david is suggesting.

<alastairc> https://github.com/w3c/wcag/pull/1487/files

alastairc: creating new PR and addition to the exception(ex: essential info) will satisfy david's needs - see https://github.com/w3c/wcag/pull/1487/files

chuck: does this satisfy andrew's needs?

<Fazio> we did

<Fazio> exactly

mikegower: the note what David is pointing and the note in PR is different.

alastairc: reading the changes.

jf: there will be time that this step/process will problematic in terms of security and testing scenario.

alastairc: we added security to essential info.

mg: we can add security/essential info as the separate note or understanding doc. need to consider the nature of work regarding essential info and so on.
… password example

<Zakim> alastairc, you wanted to say that most cases (apart from password) make the input available.

faz: we should not use this excuse for redundant entry

alastair: we needs exception for pw - some field can be coped and pasted but may not pw.

chuck summarize all the points.

alastairc: new PR will satisfy everyone's feedback.

<alastairc> https://github.com/w3c/wcag/pull/1487/files

gundula: I am fine with the PR. but do we have an use case?

mg: airline ticketing use case

<nicaise> +1

mg: choosing changed travel dates

<alastairc> +

<alastairc> +1

<Rachael> 0

<Detlev> +1

<sarahhorton> +1

<michael> +1

<JustineP> +1

<morr4> +1

+1

<Sukriti> +1

<JF> =1

<david-macdonald> +1

<JF> +1

<laura> +1

<kirkwood> +1

Resolution: Accept PR 1487 to address issue #1410

Question 3 - 3.3.8: Redundant entry - session term #1335

chuck reads the comment, request on clarification on "session"

<kirkwood> +1 to Gundula - session is a well understood technical term

gundula: session is understand differently to web developer and IT - more technical concept, 'session time out' . it is confusing concept

jf: agree with gundula - session is also related to authentification
… dictionary defintion in English can be problematic for international org like w3c

faz: I dont' see the conflict for session concept here with differen use cases.

<Zakim> alastairc, you wanted to talk about the original question

<Ryladog_> but the W3Cs official language for specs id English

<alastairc> "For example, purchasing a product might be a process, but there is no requirement to save the information to then complete a separate purchase."

<Fazio> It's almost irrelevant though

alastairc: in discussion of process and session - via versioning disucssion - I would like to suggest to stay on original comments. (he also added session of puchasing the product example)

mg: the suggested new pr will satisfy this issue.

johnkirkwood: I would want to make sure that session can be tricky term and stay way from it if possible.

<Ryladog_> +1

<Zakim> Chuck_, you wanted to ask about Katie's comment

<Zakim> alastairc, you wanted to talk about the session confusion

faz: we are not adding any new requirement - session if you close browse, you close session, I dont think we need to go further more than definition

<Fazio> thank you Alastair

<Fazio> +1 Alastair

<kirkwood> +1

alastair: agree with mike gower's suggestion, new PR will clarify issues.

+1

<michael> +1

<Fazio> +1

<Sukriti> +1

<sarahhorton> +1

<MelanieP> +1

<JF> +1

<Rachael> +1

<david-macdonald> +1

<Ryladog_> +1

<Fazio> +1

Resolution: Accept Alastair's response to address issue #1335

<alastairc> Response added: https://github.com/w3c/wcag/issues/1335#issuecomment-767681976

Question 4 - Redundant entry -- problem scenario is not inherently blocking, should be AA or AAA #1446

<Detlev> I can do it

<Sukriti> I can do it but need to leave 5 mins early

Question 4. Redundant entry

Question 4. Redundant entry

Chuck reading response

<Fazio> It only takes a second of distraction for this to happen

Gundula: Affected users have high impact, cannot complete task, like HCM users - but requirement is AAA. We have to consider number of people affected and availability of work-arounds. Should be AA but not single A

<Zakim> alastairc, you wanted to add some context

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

<Fazio> There's a lot of research in our Making Content Usable for People With Learning and Cognitive Disabilities Doc

<Fazio> comparing disabilities isn't appropriate

alastair: Info on how levels were set originally - is it essential, can it be satisfied for all contexts, are there work-arounds etc. David tackles first aspect
… 2.X structure does not account for small things builduing up - First aspect is 'essential' - fo rredundant entry it is easy to make the case it is essential.
… so good cause for level A or AA
… David uses words like 'often' so i tis not as b/w as with captions

DavidF: There is also a scale from hard-of-hearing to deaf - that's why I used term 'often'. There is research to back that up. People with cognitive issues can quickly have absolutely blocking contexts - research backs that up.

<Zakim> JF, you wanted to note that A, AA is something of a moot point

JF: at some level, difference between A and AA is moot in most legal contexts

<Fazio> It is is always what I'm saying

JF: not uncomfortable with placing it at level AA - see the difference between captions (on A) and AD (on AA)

<Zakim> Chuck_, you wanted to ask everyone if issue is just with response

<Fazio> How many people have actually read research on short term memory barriers?

Chuck: Question to all: Do you have an issue with the response, is the wording the issue or do you want it at AAA?

MikeG: Normally we tackles responses in reviews, but no we do not go through all the responses - there is no big difference between AA and A - but all points should be tackled. For an official response, we should reflect the reasons why we pick A or AA

<JF> +1 to Mike G

Chuck: So you want a different response, correct?

MikeG: yes

<alastairc> Two issues here: What is the appropriate level A or AA? And updating the response.

Sarah: agree with MikeG that we need a more complete rationale

<alastairc> "Other factors taken into consideration are ease of implementation, whether it is invisible to other users, and applies across all relevant web content. See this wiki page of a discussion of the history during WCAG 2.0 - 2.2."

Alastair: Put a suggestion to add reference to the Wiki page and other factors tasken into consideration, agree with MikeG - WG has not focused on the level

Chuck: To issues: A or AA, nominal difference - agrees it should not be AAA. Let's draft a response that takes rationale into account

Alastair: Reading out Andrew's reformulation of DavidF's response

<Fazio> We discussed this early on too

<JF> I've not seen that in practice

Sarah: As to the nominal difference between A and AA: There is a significant difference in the way backlogs / issues are handled / addressed in practice

DavidF: We discussed this earlier and put it on A - one reason was also that could be addressed quite easily. We need to look at individual cases

<alastairc> Fair point, thank you David.

<Ryladog_> +1 to David

<JF> +1 to Glenda - A & AA are usually treated as equal

<michael> Mine too

<Zakim> Chuck_, you wanted to ask about A and AA

Glenda: Clients look at AAA - they easily ignore it. A and AA get done. So disagree with Sarah.

<kirkwood> +1 to Glenda

<Fazio> good point chuck

<Glenda> Good point Chuck :)

<Fazio> hallelujah

<kirkwood> agree Chuck

<Fazio> read it please

<alastairc> AWKs Suggested response: A-level Success Criteria should be reserved for scenarios that are inherently blocking for some users in all cases." The Working Group has not clarified specific criteria to indicate which Level Success Criteria need to be a part of, and elected to place the Redundant Entry SC into Level A because it poses a significant barrier to individuals with short term memory impairments. Users with short term memory impairments

<alastairc> are often unable to complete tasks due to the amount of information that needs to be entered, and this SC places limits on information that needs to be entered more than once that are readily addressed and help reduce the barrier for these users.

Chuck: It seems if SC stays A both camps are satisfied - so regarding the response - Andrew has changed it - reactions?

Alastair: Reading Andrew's survey response

Sory Chuck read it.

DavidF: It is not just the aggregate, spoon, thing - it can be a single instance.

Alastair: Andrew suggests level A because it is easly to do - there is no requirement that all A's need to be gard blockers

Chuck: So the end result is leaving at at A

<mbgower> yes

Chuck: Becomes an amended response

<alastairc> https://github.com/w3c/wcag/issues/1446#issuecomment-767698161

<JF> +1

<mbgower> +1

<laura> +1

+1

<kherr> +1

<Ryladog_> +1

<sarahhorton> +1

<Sukriti> +1

<kirkwood> +1

<Wilco> 0

<Rachael> +1

<morr4> +1

<JakeAbma> +1

<Glenda> +1

Resolution: Accept amended response to address issue #1446

WCAG 2.2 Hidden Controls https://www.w3.org/2002/09/wbs/35422/hidden-controls-12-2020/

Question 1 - New version: Visible Controls

Chuck: (Reading the survey question - linking to issues)

Chuck: Little consensus here

Sarah: In the SC text, out control in parentheses - be consistent about pointer and KB focus - examples and benefits seems redundant

Chuck: Gundala wants to defer - why?

Gundula: The requirement does not seem to be mature
… given the discussion that has happened and the time pressure, we should defer this

Oliver: Prefer the old version of text
… what does 'information' mean in the context of the SC? Seems to mic affordance with visibility issues, these are not the same

Alastair: Agree with Sarah's comment - it has significantly changed and therefore needs to be put out for review again

<Chuck_> dav

<mbgower> +1 to Sarah's comment on adding "control" parenthetically after 'user interface component' in the SC.

DMD: We could not move forward with previous language, no way back to there
… IN most cases the info to identify the component is the component itself, but not in all cases - examples are tool tip with close button
… the info tooltip might be sufficient context for the close button. Another example would be things like Yourtube videos, it is a strong ask to require the way these videos are presented

<Zakim> alastairc, you wanted to speak to Use of controls vs UICs, and affordance / info to ID controls;

DMD: mostly info is the component itself, though

Alastair: user interface components vs. Controls needs to be clarified (perhaps with brackets)
… affordance formulation is very similar to other SCs

<Zakim> mbgower, you wanted to say I missed the survey (looked like I'd already answered). I support, and amenable to mod

Alastair: explanation is far down in the doc, should perhaps be moved up

MikeG: We use controls in other SCs but it is a good idea to out it in brackets after "user interface components"

<Zakim> kherr, you wanted to say controls shown on hover are always an issue on mobile web

<mbgower> Mobile meets it

Kerr: Agree it is a bit immature - how does it apply to mobile web where hover is not available

Alastair: it is good for mobile because then things cannot rely on things popping up on hover.
… formulation has changed a lot, but not the intent and scope - those who worry about the maturity, we will go through another public review with it

<Zakim> Chuck_, you wanted to ask on what non-consensus means

Chuck: Not clear what 'lack of consensus' means here - is it back to original, or deferral - what is the end state?

Alastair: decision tree is: issues raised on prev version - either acceopt new version (with mods) and put up for review OR come up with alternative options (likely to be a dead end) OR defer
… so it is: accept (possibly amend) OR defer - it migh tthen go to 2.3 or WCAG 3.0

Chuck: We discussed Sarah's revisions - does that make you more comfortable? (For Gundula and Oliver)

Oliver: Also suggest to defer

Oliver: Video case where an initial tab is needed to bring up control, should be discussed mire generally

<mbgower> video is directly addressed in the Understanding doc

DMD: Visible entry point that launches other controls would address that

<mbgower> -1

<sarahhorton_> -1

<david-macdonald> -1

Chuck: What is the temperature of the group?

<Ryladog_> -1

<alastairc> -1

-1

<Rachael> -1

<Sukriti> -1

<GN015> +1

<JakeAbma> -1

Chuck: Consensus is not to defer, but to incorporate changes to modify
… like Sarah's suggestions

Alastair: We cannot remove either Examples or Benefits from Understanding, but tacke overlapping

tackle

<david-macdonald> We could probably add visual examples from the previous committee document that has examples screen shotes.

<Zakim> mbgower, you wanted to say Understanding doc changes don't need to hold up the process; let's focus on Sarah's SC change.

<Rachael> +1 to Mike

MikeG: The main thing to incorporate the SC change, Understanding can change later

<david-macdonald> +1

Alastair: So there is agreement to continue and review again

<alastairc> +1

<Wilco> +1 lets please not use those terms interchangeably

Rachael: Prefers picking User interface element OR Control and make that consistent, to keep it simpler

Alastair: Will also change Focus appearance SC where that change happens

<oliverkeim> +1 for "controls" or "UI elements"

<mbgower> +1 to just changing "control" to "component"

<Wilco> +1, that's how ACT rules work too

Rachael: using component

Wilco: Suggests components

Alastair: That firs better with rest of language

<david-macdonald> Agree component has more historical usage in WCAG

<Rachael> I think the full text would then be: Information needed to identify each user interface component is visible without requiring pointer hover or keyboard focus, except when: A component with equivalent function is identifiable without requiring pointer hover or keyboard focus, either on the same page or on a different step in a multi-step process; The component is provided specifically to enhance the experience for keyboard navigation; A

<Rachael> mechanism is available to make the information persistently visible; Hiding the information needed to identify the component is essential.

Chuck (reads proposed changed SC text)

<mbgower> And the note too

<mbgower> Components can be available through a visible entry point...

<Rachael> Note: Compontents can be available through a visible entry point such as a submenu.

<mbgower> +1

+1

<Rachael> +1

<JakeAbma> +1

<david-macdonald> +1

<alastairc> +1

<sarahhorton_> +1

<GN015> -0.5 'component' is ambiguous to technical unity (in the backend)

Wilco: Would like more time to think about it - it is a complicated thing

DMD: There is a historical precedent of component over control

Chuck: We can make th echange and re-survey again...

Alastair: Wiclo can you comment before we CfC it?

Wlco: OK

Resolution: Accept amended SC change and note using the word "component" uniformly.

<alastairc> https://github.com/w3c/wcag/issues?q=is%3Aissue+is%3Aopen+label%3A%22Survey+-+Added%22

Miscellaneous Issues

Alastair: Request is to tackle a bunch of items that have been surveyed but not actioned - some came round again - some 20 are open
… what can we do to bring these back to the group - can you look at these to see what we can tidy up to close tidying up of 2.2
… (to Rachael: Some, yes, but mostly not

Alastair: Some on target spacing, others

Sukriti: What is the course of action for Pointer Target Spacing?

Alastair: case by case basis - will have a look

<alastairc> https://www.w3.org/WAI/GL/wiki/Upcoming_agendas

<alastairc> https://www.w3.org/WAI/GL/wiki/Upcoming_agendas_2020

<alastairc> https://www.w3.org/WAI/GL/minutes-history.php

Alastair: if you have time to look but not sure what happened previously, it is worth looking to the past minutes where SCs were discussed
… volume too much for one person
… Please change label to "Ready for survey" if possible