– DRAFT –
WCAG2ICT Task Force Teleconference

<Chuck> Thanks Chris!

<PhilDay> Loic is having issues joining IRC - so input will be relayed

MaryJo: IRC asks for ID, you don't have to have one of those to log in.

Announcements

MaryJo: Looks likely that we won't publish before May. Discussions are running longer than expected.
… we should read document in full before we send to AGWG for publication.
… continue to work and participate.

Status of remaining work before next publication

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

MaryJo: Work left . PR329 was started, but in progress.
… the first table , we only have two left to agree on.
… the AGWG comments, we need to do the pull request and answer to that.
… issues from task force, on issue 145, I will put that in a survey. Continued discussion on 196.
… public comments are related to reflow, we are talking to that today.
… what left is then responses, which are in Google doc. Survey may go out this week.
… Issue 4 , we've been discussing that on Friday meetings for a couple weeks.
… contribute as you can.
… no Friday meeting tomorrow. I'm on vacation this week.
… whatever we don't get to we will pursue next week on Thursday and Friday's meeting as well.

zakim , take up next

Survey results: Proposals for remaining work

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICTfinishclosed/results

Question 2: Addressing public comments on 1.4.10 Reflow

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICTfinishclosed/results#xq2

MaryJo: Talking through the survey results, starting with Reflow.

<maryjom> Content reviewed: https://docs.google.com/document/d/1TbtNcNjrpog8-6OYloMcPILh2UsqUOXBjPwVwv7dPsw/edit#heading=h.kp9yc0hnzxu7

<PhilDay> Option 3A: Mitchell’s edits to Option 3 (to replace current editor’s draft’s Notes 6 & 7)

<PhilDay> NOTE 6: As written, this success criterion can only be met by non-web documents or software where the underlying user agent or platform can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 25640 CSS pixels for horizontal scrolling content.

<PhilDay> When the underlying user agent or platform does not support these dimensions for scrolling, reflow is encouraged as this capability is important to persons with low vision. As a reasonable benchmark, evaluate at the nearest size to what the Reflow success criterion specifies.

<PhilDay> For platforms that do not support zoom, scrolling, and reflow, user needs such as low vision are often addressed by other means (including but not limited to using sufficiently large text and single screen designs).

<PhilDay> Option 3B: Sam’s edits to option 3A

<PhilDay> NOTE 6: As written, this success criterion can only be met by non-web documents or software where the underlying user agent or platform can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 25640 CSS pixels for horizontal scrolling content.

<PhilDay> When the underlying user agent or platform does not support these dimensions for scrolling, reflow is generally considered a best practice.

MaryJo: 6 said to incorporate 3A as is. 1 prefer 3b as is.

Sam: It seems a lot longer. I'm ok going with the other version if that is what is necessary.

MaryJo: Thanks for edit on dimension change on Google doc.

MaryJo: I will poll the option.

<PhilDay> Dimension change above should read 256 CSS pixels

Sam: I wanted to add one more comment. I was channeling the brevity topic. I believe we were trying to over anticipate and solutionizing .

MaryJo: Talks to removing reasonable benchmark phrasing on Google Doc.

<maryjom> POLL: Which do you prefer? 1) Incorporate Option 3A with edit of "40" to "256" to replace notes 6 and 7 of 1.4.10 Reflow 2) Incorporate Option 3B with edit of "40" to "256" to replace notes 6 and 7 of 1.4.10 Reflow or 3) Something else.

Sam: It was a reduction by those sentences, yes.

<mitch11> 1

<loicmn> 1

<PhilDay> 1, but would accept 2

<olivia> 1

<Bryan_Trogdon> 1

1 but also like Sam's too.

<FernandaBonnin> 2, but would accept 1

<mitch11> actually 3 ...

<mitch11> 3: keep 3a, but remove last paragraph

<Sam> 2, but ok with 1

Mitch: Sam has a good point on solutionizing. I think the last paragraph doesn't add much. I think the benchmark sentence should stay as it is in scope.

Sam: On equivalent benchmark, I agree that could be left in.

<maryjom> POLL: Which do you prefer? 1) Incorporate Option 3A with edits of "40" to "256" and removing last paragraph to replace notes 6 and 7 of 1.4.10 Reflow 2) Incorporate Option 3B with edit of "40" to "256" to replace notes 6 and 7 of 1.4.10 Reflow or 3) Something else.

<Sam> 1

1

<loicmn> 1

<olivia> 1

<mitch11> 1

<Bryan_Trogdon> 1

<PhilDay> 1

<PhilDay> Latest version of 3A with all edits above: NOTE 6: As written, this success criterion can only be met by non-web documents or software where the underlying user agent or platform can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 256 CSS pixels for horizontal scrolling content.

<PhilDay> When the underlying user agent or platform does not support these dimensions for scrolling, reflow is encouraged as this capability is important to persons with low vision. As a reasonable benchmark, evaluate at the nearest size to what the Reflow success criterion specifies.

RESOLUTION: Incorporate Option 3A with edits of "40" to "256" and removing last paragraph to replace notes 6 and 7 of 1.4.10 Reflow.

Question 3: SC Problematic for Closed: 2.4.4 Link Purpose (In Context)

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICTfinishclosed/results#xq3

<maryjom> Content reviewed: w3c/wcag2ict#274 (comment)

<PhilDay> Option 1: Proposal from the 15 March Friday discussion

<PhilDay> 2.4.4 Link Purpose (In Context) - Assumes the use of text and context made available in a programmatically determinable form.

MaryJo: Shares Github issue 274 comment from Mike.

<PhilDay> Option 2: Using replacement for "requires" replacement in Issue #329

<PhilDay> 2.4.4 Link Purpose (In Context) - This success criterion relies upon text and context made available in a programmatically determinable form.

<PhilDay> Option 3: Mike's edit:

<PhilDay> 2.4.4 Link Purpose (In Context) - This success criterion relies upon text and context being made available in a programmatically determinable form.

adds in word "being" made available.

<maryjom> DRAFT RESOLUTION: Incorporate Option 3, with small edit to add “being” as shown in the meeting minutes.

<loicmn> +1

<mitch11> +1

<PhilDay> +1

<FernandaBonnin> +1

MaryJo: Option 3 per meeting minutes.

<Sam> +1

+1

<Bryan_Trogdon> +1

<olivia> +1

RESOLUTION: Incorporate Option 3, that has the small edit to add “being” as shown in the meeting minutes.

MaryJo: Topic of images of text results in survey

Question 4: SC Problematic for Closed: 1.4.5 Images of Text

<maryjom> Survey results: https://www.w3.org/2002/09/wbs/55145/WCAG2ICTfinishclosed/results#xq4

<maryjom> Content reviewed: https://docs.google.com/document/d/1fpa7fX2Hdov3lduiJtSzb0EGSflSlxivtKmKGMsMobs/edit#heading=h.v13ly0jz2vqu

MaryJo: 2 prefer 9 as is, 3 prefer option 11 and 2 prefer option 11 with edits.

MaryJo: Reads through results comments per survey link results page.

<PhilDay> Option 9: Only state the problem

<PhilDay> 1.4.5 Images of Text—Requires text for high-quality modification of displayed text (e.g. high contrast, increase of font size). Not all ICT with closed functionality has the capability to support visual modification of displayed text or images of text, given there is no interoperability with assistive technology and/or lack of platform support.

<PhilDay> Option 11: Only state the problem, more detail

<PhilDay> 1.4.5 Images of Text—High-quality machine-readable text (and not mere images of text) is needed for assistive technology functionality to provide modification of displayed text (e.g. high contrast, increase of font size). Not all ICT with closed functionality has the capability to support visual modification of displayed text or images of text,

<PhilDay> given there is no interoperability with assistive technology and/or lack of platform support.

<maryjom> Option 12: Olivia's edits

<maryjom> 1.4.5 Images of Text—To enable assistive technology to modify displayed text (e.g., adjusting contrast, increasing font size), high-quality machine-readable text is needed, as opposed to mere images of text.

MaryJo: Will place poll in IRC to review.

<maryjom> Poll: Which do you prefer? 1) Option 9, 2) Option 11, 3) Option 12, or 4) Something else

<PhilDay> 3, but would accept others

<mitch11> 3

<loicmn> 3, can accept others

<FernandaBonnin> 3

<Sam> 3

<olivia> 3

<Bryan_Trogdon> 3

3

that is how I read it, and voted.

<PhilDay> Option 12: Olivia's edit

<PhilDay> 1.4.5 Images of Text—To enable assistive technology to modify displayed text (e.g., adjusting contrast, increasing font size), high-quality machine-readable text is needed, as opposed to mere images of text.Not all ICT with closed functionality has the capability to support visual modification of displayed text or images of text, given there is

<PhilDay> no interoperability with assistive technology and/or lack of platform support.

thanks! Was just going to ask that

Mitch: Suggests removing "high quality" text means in context.

<PhilDay> +1 to Mitch's suggestion

<Sam> suggest changing high quality to informative?

Mitch: Problematic, some systems may not be able to use text due to close systems.

<PhilDay> Option 12: Olivia's edit, and Mitch's tweak

<PhilDay> 1.4.5 Images of Text—To enable assistive technology to modify displayed text (e.g., adjusting contrast, increasing font size), machine-readable text is needed, as opposed to mere images of text. Not all ICT with closed functionality has the capability to support visual modification of displayed text or images of text, given there is no

<PhilDay> interoperability with assistive technology and/or lack of platform support.

+1 to Mitch's recommendation for high quality definition term.

Sam: On the term high quality, would you welcome a substitute word instead?

Mitch: I just think it adds confusion as to what high quality means.

Sam: I'm ok with that edit.

<maryjom> DRAFT RESOLUTION: Incorporate Option 12 as shown in the meeting minutes.

<loicmn> +1

Option 12 is within minutes in IRC FYI

+1

<FernandaBonnin> +1

<mitch11> +1

<PhilDay> +1

<Bryan_Trogdon> +1

<olivia> +1

<Sam> +1

RESOLUTION: Incorporate Option 12 as shown in the meeting minutes.

Question 1: Can a non-web software act as, or have, a conforming alternate version?

<maryjom> Survey results: https://www.w3.org/2002/09/wbs/55145/WCAG2ICTfinishclosed/results#xq1

MaryJo: Survey question 1, alternate version topic

<maryjom> Discussion topic – newer posts: https://github.com/w3c/wcag2ict/discussions/310#discussioncomment-8933556

MaryJo: We didn't get a chance to discuss it last week.
… 7 stated agree, don't make changes. 1 disagreed , changes are needed.

MaryJo: Reads Bruce's comment on regulators needing advice.
… WCAG definition explores specific cases. Non web cases this may not occur. The definition as written may not apply fully.

MaryJo: Shows discussions 310 thread via Zoom.

MaryJo: goes through that this is a case by case basis.
… talks to accessibility settings and changes UI as a use case.
… human language topic, may not be same language, may be in sign language.
… talks to Shadi's comments regarding Alexa and responses from Alexa (voice) vs. web app vs. mobile app, topic of fully conformant vs. focused user interaction.

Phil: I agree with consensus, however I would like his input on your comments without resolution.

Chuck: Expressing concerns and opinion on AGWG may think this is out of scope. Looking at charter, this doesn't fit within WCAG2ICT.

MaryJo: We can't state what is and what isn't an alternate conversion , we can't propose WCAG definition . We could raise where it is problematic due to "X, Y, Z".

MaryJo: Should we go that far or leave as is?

Sam: Is Section 508 or ETSI , is there the ability to add more on the what is and what is not within those groups? Someone needs to do something. Without guidance , there isn't clarity.

Sam: I would agree it is questionable within our work within WCAG2ICT. Where else would this come from?

MaryJo: Mike commented in February on EN 301

<maryjom> Mike's comment: https://github.com/w3c/wcag2ict/discussions/310#discussioncomment-8629850

MaryJo: EN did not make an attempt on this topic per Mike's comment in GitHub.

Mitch: Re-reading Mike's comment, he seems to be saying that it is within their remit, but equivalence across technology.
… Section 508 would possibly allow this through equivalent facilitation, not systematic, but doesn't preclude.
… Section 508 should provide guidance on this in training material.

<Zakim> loicmn, you wanted to say that EN 301 549 does not apply conformance requirements outside of web

Mitch: clarification on what page means in our remit.

Loic: We did agree outside of web. Equivalence wouldn't be an alternate.

Loic: The web accessibility directive is also talking to this topic. We shouldn't do anything in WCAG2ICT.