– DRAFT –
WCAG2ICT Task Force Teleconference

Announcements

<maryjom> https://github.com/w3c/wcag2ict/wiki/Work-left-for-second-public-draft

Mary Jo has updated the wiki page showing what is left to do for the 2nd draft

Now in tabular form. Feel free to pick some of the work up

For work to be done, in most cases there are already issues created - just assign yourself to an issue. Please take 1 or 2

<Zakim> bruce_bailey, you wanted to ask about AAA

bruce_bailey: Table is useful. Looking for what we decided on AAA.

maryjom: We will go out with WCAG2ICT without AAA to get it out in time for EN 301 549 refresh
… After it is published, we could address AAA if there is interest and availability
… So it is not included in the table of work left

Comments on Closed Functionality, definition of “closed functionality”

<maryjom> w3c/wcag2ict#307 and w3c/wcag2ict#306

There were not many responses on the surveys for closed functionality

Are all happy with the changes in these pull requests?

<maryjom> • DRAFT RESOLUTION: Incorporate PRs 306 and 307 for Comments on Closed Functionality and “closed products” definition updates.

No objections, so drafting resolution

<Sam> +1

+1

<loicmn> +1

<bruce_bailey> +1

<FernandaBonnin> +1

<Bryan_Trogdon> +1

RESOLUTION: Incorporate PRs 306 and 307 for Comments on Closed Functionality and “closed products” definition updates.

<Devanshu> +1

Survey results for 2.4.8 Target Size (Minimum) and 3.3.8 Accessible Authentication

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-miscellaneous-changes/results

First 2 questions were for target size, rest for accessible auth

1st q. All said incorporate new note as is

<maryjom> New note that was proposed for 2.5.8 Target Size (Minimum): Note 3: In technologies where CSS is not used, the definition of 'CSS pixel' applies as described in Applying “CSS pixel” to Non-Web Documents and Software.

There are other SCs that point to CSS pixel. Should we add the same note in these to draw attention to the definition?

<bruce_bailey> +1 for adding this note to other SC if needed

<loicmn> +1 to add this note to any SC using "CSS pixel"

(e.g. SC for reflow)

+1 to add this note elsewhere

<maryjom> DRAFT RESOLUTION: Incorporate the above note proposed for 2.5.8 as-is to that SC and others that link to CSS Pixel definition.

+1

<loicmn> +1

<olivia> +1

<Devanshu> +1

<Sam> +1

bruce_bailey: Prefer to have the SC referred to by number

<maryjom> DRAFT RESOLUTION: Incorporate the above note proposed for 2.5.8 as-is to that SC and to 1.4.10 and "perimeter" definition.

<loicmn> +1

<Devanshu> +1

+1

<Sam> +1

<bruce_bailey> +1

RESOLUTION: Incorporate the above note proposed for 2.5.8 as-is to that SC and to 1.4.10 and "perimeter" definition.

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-miscellaneous-changes/results#xq2

Now onto q2 in the survey.

<bruce_bailey> https://github.com/w3c/wcag2ict/wiki/Work-for-the-week#preparation-for-the-1-february-meeting

Survey results were mixed. Some changes requested. Fernanda - examples for unknown viewing distance. Mitch also gave comments

Mitch also had some small edits on language & typos

Sam: (Asked for examples). Onscreen controls that might be used in multiple contexts (e.g. used on many displays from signage to TVs to computer monitors). Onscreen display is out of the control of the designer/developer - it is unknown what the size is as the target varies

FernandaBonnin: Is this software used in different modalities, so is the viewing distance still unknown?

Sam: No, it is unknown as you don't know where it will be used

<maryjom> NOTE 1: If the viewing distance and pixel density of the system is unknown, approximating the reference pixel as described in Applying “CSS pixel” to Non-Web Documents and Software is not possible."

<maryjom> above was Mitch's proposed change to note 1

mitch11: (correcting a typo in the above paste)

<maryjom> NOTE 1: If the viewing distance and pixel density of the system are unknown, approximating the reference pixel as described in Applying “CSS pixel” to Non-Web Documents and Software is not possible."

bruce_bailey: If you have a flat panel display, who knows where it will end up.

<bruce_bailey> thank you mitch, then "and" is correct

mitch11: Used AND because our interpretation of CSS pixel - only need one of device independent pixels or viewing distance to approximate the reference pixel

<bruce_bailey> +1

<Sam> +1

<maryjom> Poll: Do you agree with the above Note 1?

+1

<loicmn> +1

<olivia> +1

<mitch11> +1

<FernandaBonnin> +1

<Devanshu> +1

note 2

Now discussing Note 2 in 2.5.8 target size SC problematic for Closed Functionality: https://deploy-preview-300--wcag2ict.netlify.app/#success-criteria-problematic-for-closed-functionality

(and survey results above)

<maryjom> NOTE 2: For software designed to run on specific known hardware, a physical size standard would be more straightforward to apply, as calculations for CSS pixels are dependent on the viewing distance *or* pixel density of the display.

mitch11: Took pixel density to be shorthand for device independent pixel.
… density

<Zakim> bruce_bailey, you wanted to ask if "calculations for CSS pixels" should be plural ?

bruce_bailey: calculations AND pixels? should it not be calculations of CSS pixel?

<mitch11> I agree this would be better: calculations of the CSS pixel

<bruce_bailey> NOTE 2: For software designed to run on specific known hardware, a physical size standard would be more straightforward to apply, as calculations for CSS pixel are dependent on the viewing distance *or* pixel density of the display.

<mitch11> what bruce said

This will go in the closed functionality section

(SC problematic for closed)

<Zakim> PhilDay, you wanted to say Note 2 gives an indication of how to solve it

<bruce_bailey> labeled as note 2 in survey, but is note 6 in preview URL

<maryjom> NOTE 2: For software designed to run on specific known hardware, a physical size standard would be more straightforward to apply, as calculations for a CSS pixel are dependent on the viewing distance *or* pixel density of the display.

<Zakim> GreggVan, you wanted to say if you want to make pixel singular you need to add "a" in front of pixel

Sam: There are other requirements that are already in EN (e.g. closed to zooming)

<GreggVan> +1

<maryjom> Poll: Are you ok with the above language for note 2?

<bruce_bailey> +1

<Sam> +1

+1

<olivia> +1

<GreggVan> +1

<loicmn> +1

<mitch11> +1

<FernandaBonnin> +1

RESOLUTION: Incorporate Notes 1 and 2 as edited above into the SC problematic for Closed functionality for SC 2.5.8 Target Size (Minimum).

Survey results for the public comment responses

Survey results for 2.4.8 Target Size (Minimum) and 3.3.8 Accessible Authentication

3.3.8 accessible authentication

Now on q3

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-miscellaneous-changes/results#xq3

All said to incorporate content up to notes as is, then work through notes

RESOLUTION: Incorporate guidance for SC 3.3.8 Accessible Authentication up to the notes (per question 4 in the survey) as-is.

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-miscellaneous-changes/results#xq4

Now q4 in the survey: review note 3 of SC 3.3.8

Mixed results. Bruce suggested dropping as device = hardware

<maryjom> https://docs.google.com/document/d/1op2IO_LEUr9hafvX1doPkwZ2iV1928o_dKgBVl5UYQk/edit?usp=sharing

Mitch proposed a different option in the google doc

<bruce_bailey> Mitch's option 2 from google doc addresses my concern about 'device'

(Now discussing Note 3 Option 2)

<bruce_bailey> i did not go back to survey after Mitch submitted his survey responses

bruce_bailey: Software for the device may be more correct, rather than device.

PhilDay: Proposed Passwords used to unlock a SYSTEM (rather than device

Mitch & Fernanda happy with change

<maryjom> Note 3 Option 2: NOTE 3: Device passwords, used to unlock a system, are out of scope for this requirement when they are not up to the author.

<maryjom> Proposed NOTE 3: Passwords used to unlock a system are out of scope for this requirement when they are not up to the author.

<Sam> +1

<bruce_bailey> +1

<loicmn> +1

<maryjom> Poll: Are you good with the above edits for Note 3?

<olivia> +1

+1

<olivia> +1

<mitch11> +1

<FernandaBonnin> +1

<GreggVan> +1

GreggVan: How can a password not be up to the author? If system generates a password

<bruce_bailey> The system author is different than document/software author

mitch11: Think the note we just voted for is fine.
… in context of what we are referring to (accessible authentication). An example for this is a piece of software that is a password vault

<Zakim> PhilDay, you wanted to say system author not the same as the software author

<Zakim> bruce_bailey, you wanted to suggest > Unlocking a system is out of scope for this requirement when they are not up to the author.

bruce_bailey: suggested a change of words

<bruce_bailey> Unlocking a system is out of scope for this requirement when the means of unlocking is not up to the author.

mitch11: Concern that Gregg raised - platform is software -was relevant to option 1 of note 3, that is why option 2 of note 3 was added. And agree change to unlocking the system rather than referring to password

<maryjom> NOTE 3: Passwords used to unlock the underlying platform or system are out of scope for this requirement when they are not up to the author.

GreggVan: Now happy with the change

<bruce_bailey> +1

q:

<FernandaBonnin> +1

<maryjom> Poll: Do we like the above change?

<Sam> -1

<mitch11> +1

<loicmn> +1

Sam: Not clear why we are making further changes - there are other notes in this example, and think note 3 was clear in the original version

Have to continue this conversation next week.

+1 to stay and resolve

GreggVan: Think that the last version helps and solves the issue.

<Sam> sorry I have to drop

Can't close it out as we've lost more people, so will send via email.

Extra meeting is happening tomorrow