W3C

– DRAFT –
WCAG2ICT Task Force Extra Friday Meeting

31 May 2024

Attendees

Present
bruce_bailey, Daniel, GreggVan, loicmn, maryjom, Mike_Pluke, mitch11, PhilDay, Sam
Regrets
-
Chair
Mary Jo Mueller
Scribe
PhilDay

Meeting minutes

3 qs left from survey that we didn't cover yesterday... Plus Microsoft issue

Question 9 – (4 of 6) SC Problematic for Closed – 2.1.1 Keyboard

<maryjom> https://www.w3.org/2002/09/wbs/55145/wcag2ict-updated-proposals-24May/results#xq9

<bruce_bailey> https://github.com/w3c/wcag2ict/wiki/Work-for-the-week#31-may-extra-friday-meeting

Discussion yesterday - and, or, nor

<maryjom> https://www.w3.org/2002/09/wbs/55145/wcag2ict-updated-proposals-24May/results#xq9

<bruce_bailey> https://docs.google.com/document/d/1mgC_YiHl5qgoLmcCYacwfEziHnr1zVZnAMzEMPCF9Io/edit#heading=h.o2wm3wq8jci9

<maryjom> https://docs.google.com/document/d/1mgC_YiHl5qgoLmcCYacwfEziHnr1zVZnAMzEMPCF9Io/edit#heading=h.olmquf7e2ub

Changes are in Google doc - link above

bruce_bailey: Was looking for one with NOR, couldn't find it, so added as option 6.
… Also think we now have 3 conditions, not 2 as before
… option 6 therefore has 2 NORs

<Sam> can you put google doc link again

<loicmn> https://docs.google.com/document/d/1mgC_YiHl5qgoLmcCYacwfEziHnr1zVZnAMzEMPCF9Io/edit#heading=h.olmquf7e2ub

<bruce_bailey> SC 2.1.1: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

PhilDay: Option 7 - try to remove need for NOR - so had any of the following (LIST OPTION 1 or OPTION 2 or OPTION 3), ...

<bruce_bailey> the (a) (b) (c) really helps with readability

[editing by multiple people in Google doc]

There was a mention of removing "standard keyboard" and just use "keyboard".

Mike_Pluke: if we remove standard, then we have keyboard or alternative keyboard - seems repetitive.

bruce_bailey: 8 looks ready. 7 may need more work.

[now up to 10 options]

<maryjom> https://docs.google.com/document/d/1mgC_YiHl5qgoLmcCYacwfEziHnr1zVZnAMzEMPCF9Io/edit#heading=h.o2wm3wq8jci9

Mike_Pluke: Gregg's last - default keyboard. May be helpful
… could be added into 7.

bruce_bailey: Question on 9 - does it allow alternative input devices such as EZ Access or uNav to pass?

GreggVan: Yes - it is an alternative input / keyboard

Mike_Pluke: Does not provide or allow connection of - change to option 9

daniel-montalvo: Question on "it" in a or b. Not sure what this refers to.

Option 9: (any of the following)

2.1.1 Keyboard - Assumes operation via a keyboard interface which also allows for alternative input devices. It may not be possible to satisfy this success criterion when a) the ICT does not have a built-in keyboard, and b) it does not provide or allow installation or connection of an alternative input method (hardware or software) that provides

keyboard-like functionality. It may be possible to address some user needs (such as offering input methods that support users with low vision, without vision, or limited manual dexterity).

<loicmn> +1 to 9

+1 to option 9

Option 9: (any of the following)

2.1.1 Keyboard - Assumes operation via a keyboard interface which also allows for alternative input devices. It may not be possible to satisfy this success criterion when a) the ICT does not have a built-in keyboard, and b) it does not provide, or allow installation or connection of, an alternative input method (hardware or software) that provides

keyboard-like functionality. It may be possible to address some user needs (such as offering input methods that support users with low vision, without vision, or limited manual dexterity).

Option 9: (a or b)

2.1.1 Keyboard - Assumes operation via a keyboard interface which also allows for alternative input devices. It may not be possible to satisfy this success criterion when a) the ICT does not have a built-in keyboard, and b) it does not provide, or allow installation or connection of, an alternative input method (hardware or software) that provides

keyboard-like functionality. It may be possible to address some user needs (such as offering input methods that support users with low vision, without vision, or limited manual dexterity).

mitch11: last sentence needs work

Option 9: (a or b)

2.1.1 Keyboard - Assumes operation via a keyboard interface which also allows for alternative input devices. It may not be possible to satisfy this success criterion when a) the ICT does not have a built-in keyboard, and b) it does not provide, or allow installation or connection of, an alternative input method (hardware or software) that provides

keyboard-like functionality. It may be possible to address some user needs by offering input methods that support users with low vision, without vision, or limited manual dexterity.

Above is Mary Jo's suggestion

mitch: coming round to deleting the last sentence - it's getting confusing.

Option 9c: a or b, no last sentence

2.1.1 Keyboard - Assumes operation via a keyboard interface which also allows for alternative input devices. It may not be possible to satisfy this success criterion when a) the ICT does not have a built-in keyboard, and b) it does not provide, or allow installation or connection of, an alternative input method (hardware or software) that provides

keyboard-like functionality.

GreggVan: Agree with mitch

<bruce_bailey> Does anyone disagree that an ATM with keypad (but no keyboard) passes SC 2.1.1 ?

<Zakim> bruce_bailey, you wanted to ask if ATM with keypad (but no keyboard) passes SC 2.1.1 ?

GreggVan: editing option 10

mitch: is a keyboard a keypad? can be, but also can not be in other contexts. We should avoid commenting on this.

Sam: Let's avoid keypad as it can be debated. Without it is fine. Could have arrow keys and a selector - could be an alternative.

GreggVan: talking through option 10. A keypad that provides full access to functionality could be considered a keyboard.
… Just giving clues to those working on closed functionality.

Mike_Pluke: What Gregg has written (in option 10) is useful

<bruce_bailey> Option 10 is good enough IMHO

mitch: I can accept it, but not always true, but OK to just give indication

<Sam> 9c

<bruce_bailey> Option 9c is also good enough IMHO

Sam: Agree that 9c is easier to read.

GreggVan: Writing this with an eye to other groups like EN 301 549 - so we should include content that is helpful.

<bruce_bailey> How about an "examples" sentence at end of 9c?

bruce_bailey: 9c plus examples.

<maryjom> POLL: Which should we take to the group to review? 1) Option 9c, 2) Option 10, or 3) both.

<mitch11> 3 or 2 or 1

<Mike_Pluke> 2

3, as we can't agree!

<bruce_bailey> (2) option 10

<loicmn> 2

<Sam> 3

<GreggVan> 3 or 2

<GreggVan> sorry 2 or 3

Sam: keypad - that could be added by other standards.

<bruce_bailey> I like keypad being mentioned.

Consensus is to take both option 9c and 10 to the TF

Question 8: (3 of 6) SC Problematic for Closed – 1.4.10 Reflow

<maryjom> https://www.w3.org/2002/09/wbs/55145/wcag2ict-updated-proposals-24May/results#xq8

2 incorporate as is, 5 with edits

<bruce_bailey> https://docs.google.com/document/d/1mgC_YiHl5qgoLmcCYacwfEziHnr1zVZnAMzEMPCF9Io/edit#heading=h.dqz0n45et7b3

<maryjom> Google doc: https://docs.google.com/document/d/1mgC_YiHl5qgoLmcCYacwfEziHnr1zVZnAMzEMPCF9Io/edit#heading=h.dqz0n45et7b3

Gregg proposed new version (now option 3).

Mary Jo took this and made further edits

<bruce_bailey> CLEAN VERSION OF OPTION 4 for easier readability:

<bruce_bailey> 1.4.10 Reflow - Some software on ICT with closed functionality does not support scrolling content, or zooming or changing the viewport (examples include software for self-service transaction machines or kiosks). Therefore, other non-WCAG requirements would be needed for products with closed functionality to ensure that content is readable without

<bruce_bailey> scrolling in two directions.

Option 3: Gregg’s survey edits of Option 2

1.4.10 Reflow - Some software on ICT with closed functionality does not support scrolling content, or zooming or changing the viewport (examples include software for self-service transaction machines or kiosks). So some other means of ensuring that content is readable without horizontal scrolling is needed and would need to be addressed through

other non-WCAG-like requirements on closed functionality.

CLEAN VERSION OF OPTION 4 for easier readability:

1.4.10 Reflow - Some software on ICT with closed functionality does not support scrolling content, or zooming or changing the viewport (examples include software for self-service transaction machines or kiosks). Therefore, other non-WCAG requirements would be needed for products with closed functionality to ensure that content is readable without

scrolling in two directions.

Option 4 shows all the changes including the comment from Chris

Chris OK with that.

Phil likes option 4

<loicmn> +1 to option 4

bruce_bailey: OK with therefore. But it is a strange word to put in.

<Sam> +1 to op 4

"As a result, some other means..."?

bruce_bailey: missing the word "some"

mitch: Overall these are good. One bit confuses me: some software where scrolling doesn't happen. Why and/or in next bit?

<Zakim> PhilDay, you wanted to suggest As a result, some. instead of "therefore"

mitch: maybe we should just remove mention of systems without scrolling.

mitch: Main point to address is whether system supports zooming

<bruce_bailey> The word "therefore" appears 20 times in 2013 wcag2ict

GreggVan: Alternative to 200% zoom is to just use sufficiently large text.

<bruce_bailey> i am not sure why it bothered me here

mitch: I can accept it if others are happy

<bruce_bailey> i understand where mitch is coming from, but still am okay where we are

<maryjom> Poll: Should we go to the full TF with option 4? 1) Yes or 2) No

<loicmn> 1

Latest option 4: CLEAN VERSION OF OPTION 4 for easier readability:

1.4.10 Reflow - Some software on ICT with closed functionality does not support scrolling content, or zooming or changing the viewport (examples include software for self-service transaction machines or kiosks). Therefore, some other non-WCAG requirements would be needed for products with closed functionality to ensure that content is readable

without scrolling in two directions.

<Mike_Pluke> 1

<ChrisLoiselle> 1

<mitch11> 1

<GreggVan> +1

<bruce_bailey> +1

1

<Sam> 1

We will take option 4 to the TF

<ChrisLoiselle> hard stop at 30mins

<ChrisLoiselle> +1000 to going!

Question 1 - (1 of 3) Update definition of “closed functionality”

<maryjom> https://www.w3.org/2002/09/wbs/55145/wcag2ict-updated-proposals-24May/results#xq1

<maryjom> https://docs.google.com/document/d/1mgC_YiHl5qgoLmcCYacwfEziHnr1zVZnAMzEMPCF9Io/edit#heading=h.sz1je9cnbwy6

Went to TF with options 1 & 3 in the Google doc

Bruce had some edits to create option 4

Option 1: Original definition

closed functionality (as used in WCAG2ICT)

a property or characteristic that prevents users from attaching, installing, or using assistive technology

Option 3: (Loïc’s update) Proposed updated definition

closed functionality (as used in WCAG2ICT)

a property or characteristic that prevents users from attaching, installing, or using either assistive technology or the accessibility features built into platform software

Option 4: Bruce’s edits to Option 3 from the survey comments

closed functionality (as used in WCAG2ICT)

a property or characteristic that prevents users from attaching, installing, or using either assistive technology, or that otherwise limits users to the accessibility features built into platform software

Loic: maybe we need a new note to explain assistive technology

GreggVan: Big problem here - when you have a product with some built in functionality
… it does not provide all functionality that all bolt on AT could provide
… some products may only offer 1 or 2 pieces of accessibility functionality
… also differentiate between platform and application issues

<maryjom> ak Sam

Sam: This a definition. We can address the issue that Gregg mentioned elsewhere - not in the definition, otherwise it becomes confusing.
… We use the term elsewhere. We should try and keep similar to EN and Section 508.

mitch: Undecided. Like Sam's point. Like Gregg's point. Any system that prevents attaching AT is closed. In addition, a system may stop users from using built in AT that would also be closed.

GreggVan: Think Sam is correct - that is the definition of closed.
… Question is what about AT in platform? We should address that in SC problematic for closed (along with other similar issues)

Mike_Pluke: EN may change definitions - so WCAG2ICT could change defintion if needed. We should attack the elephant in the room

bruce_bailey: From survey, nobody rejected option 1, so we should go for that.

bruce_bailey: Historically there has been a problem with people asking how an iPhone can be closed. Think option 4 addresses that, but suggest we go with option 1.

Decision: Go with option 1.

<maryjom> Poll: Go with option 1 for definition of closed functionality, as-is...

+1

<Sam> +1

<bruce_bailey> +1

<loicmn> +1

<Mike_Pluke> +1

<mitch11> +1

<GreggVan> +1

<ChrisLoiselle> +1

Issue 377 - Feedback from Microsoft on Reflow notes 5 and 7

<maryjom> w3c/wcag2ict#377

<maryjom> Google doc: https://docs.google.com/document/d/1CHa6DX3xsT13Li6NPwCxblVFqN29oQBd4aLnB_I0A3Q/edit#heading=h.aejcenfg2cfy

Microsoft concerns: Note 5 doesn't specify viewport size, so proposed adding this.
… Note 7 comments on resizing at app or OS level

<maryjom> https://docs.google.com/document/d/1CHa6DX3xsT13Li6NPwCxblVFqN29oQBd4aLnB_I0A3Q/edit#heading=h.lw4p7ltjmk6o

maryjom: Concerned about adding "up to" pixel sizes.

GreggVan: Accept their edits to note 5, but remove the "up to". We add the pixel sizes.
… Also confused by "meeting the normative requirement". Which requirement? This one? Another one?

maryjom: Change to "meeting this success criterion"

<maryjom> ac mitch

mitch: Agree with these edits

[Edits in google doc, option 2, note 5]

mitch: Change px to CSS pixels

Option 2: Note 5 - Microsoft’s Proposed Adjustment (with edits)

NOTE 5: The intent section refers to the ability for content to reflow (equivalent to 320 CSS pixels wide for vertical scrolling content or 256 CSS pixels tall for horizontal scrolling content) when a user agent zooming is used to scale content or when the viewport changes in (size). For non-web software, this means that when users scale

content, adjust the size of a window or dialog, or change the screen resolution, the content will reflow meeting this success criterion without loss of information or functionality, and without requiring scrolling in two dimensions; or that the application works with platform features to meet this success criterion.

<ChrisLoiselle> +1 to 2

<maryjom> Poll: Go forward with Option 2? 1) Yes or 2) No

<loicmn> 1

<Mike_Pluke> 1

<Sam> 1

<ChrisLoiselle> 1

<bruce_bailey> +1

<mitch11> 1

Option 2: Note 5 - Microsoft’s Proposed Adjustment (with edits)

NOTE 5: The intent section refers to the ability for content to reflow (equivalent to 320 CSS pixels wide for vertical scrolling content or 256 CSS pixels tall for horizontal scrolling content) when user agent zooming is used to scale content or when the viewport changes in size. For non-web software, this means that when users scale content,

adjust the size of a window or dialog, or change the screen resolution, the content will reflow meeting this success criterion without loss of information or functionality, and without requiring scrolling in two dimensions; or that the application works with platform features to meet this success criterion.

+1

q;

Mike_Pluke: Middle paragraph breaks up the logic of the other paragraphs. Can we move it down.

GreggVan: Changed to say "the stated dimensions"

GreggVan: Move it last to improve flow as Mike suggested

mitch: Not happy with poor user experience, so will draft an alternative.

We will bring both alternatives to the TF in the survey.

<ChrisLoiselle> need to drop for another customer facing call, I trust the people here to move forward with rest of tasks in this call.

<bruce_bailey> the word "which" is unclear

and could lead to a ...

We will take option 3, and Mitch's edit to survey to the TF

Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).

Diagnostics

Succeeded: s/mzy/

Maybe present: daniel-montalvo, Decision, Loic, mitch

All speakers: bruce_bailey, daniel-montalvo, Decision, GreggVan, Loic, maryjom, Mike_Pluke, mitch, mitch11, PhilDay, Sam

Active on IRC: bruce_bailey, ChrisLoiselle, dmontalvo, GreggVan, loicmn, maryjom, Mike_Pluke, mitch11, PhilDay, Sam