– DRAFT –
WCAG2ICT Task Force Teleconference

Announcements

MaryJo: For webpage updates for WCAG2ICT , PR was made with edits from W3C staff. Will review detail off of word document. Focus is on EN at moment.

MaryJo: We are making good progress. All issues have PRs except one. We will collate what has changed and make sure it can be incorporated.

Gregg: Do you have copy with latest with resolutions?

Daniel and Gregg, We can send after meeting of JTB on what was decided.

MaryJo: Any other announcements?

MaryJo: In AG working group, we will want to publish WCAG2ICT update and have been advised that a review will be coming soon. Process is in place. 2 to 3 weeks from now.

PR Proposal approvals

Issue 605 - 4.1.2 Name, Role, Value: clarify that non-web software does not have a user agent

<maryjom> Link to issue 605: w3c/wcag2ict#605

<maryjom> Link to PR 721: w3c/wcag2ict#721

MaryJo: We had made changes.

<maryjom> https://deploy-preview-721--wcag2ict.netlify.app/#applying-sc-4-1-2-name-role-value-to-non-web-documents-and-software

MaryJo: Bruce asked for removal of "the" . We also bolded some text.

MaryJo: Any further questions?

Bruce: Second line still has "the underlying". Need to edit out that "the" too. Note to remove "the" on word replacement.

I failed as editor. Thanks Bruce!

Issue 636 - Page Titled decision to make separate headings for SW vs. documents may cause other changes

<maryjom> Link to issue 636: w3c/wcag2ict#636

<maryjom> Link to original PR 716: w3c/wcag2ict#716

<maryjom> Link to Proposal 2 in PR 723: w3c/wcag2ict#723

MaryJo: We are separating 4 SCs.

<maryjom> For SCs SCs 2.4.1, 2.4.5, 3.2.3, and 3.2.4

MaryJo: At end of meeting, came up with idea to combine them.

Deploy preview 723 shows combined language

MaryJo: talks through note edits.

MaryJo: One is different sections , one is not.

<maryjom> POLL: Which proposal do you prefer? Proposal 1 - PR 716, or Proposal 2 - PR 723.

<loicmn> 2

Bruce: The context is just for the "sets of"?

MaryJo: Yes.

<GreggVan> COMBINED

<LauraM> Agree, combined

<GreggVan> 2 - combined

Gregg: First one is separate and PR723 is combined?

MaryJo: yes.

I vote for 2

Bruce: I appreciate keeping them separate.

Gregg: It may beneficial to apply the ones to software and documents.

Bruce: It would renumbering.

Gregg: Could be first software note.

MaryJo: Note 2 would be moved too.

Gregg: I think keeping together helps EN otherwise it may cause redundancy

Gregg: For comparison, combining makes it easier for variety of users.

MaryJo: Bruce?

Bruce: I feel we are saying same thing now.

MaryJo: Adjust PR that all software notes are together.

PR 723 for reference

<maryjom> DRAFT RESOLUTION: Adjust PR 723 to consolidate non-web software notes together for SCs 2.4.1, 2.4.5, 3.2.3, and 3.2.4 and merge into editor's draft

<bbailey> +1

<loicmn> +1

<ChrisLoiselle> +1

<GreggVan> +1

Issue 706 - 3.1.2 Language of Parts: EN 301 549 has an extra note for non-web docs - do we need it in WCAG2ICT?

<maryjom> Link to issue 706: w3c/wcag2ict#706

<maryjom> Link to PR 714: w3c/wcag2ict#714

MaryJo: There are different proposals. I will share built version.

<maryjom> Proposal 1:

<maryjom> Inheritance is one common method. For example a non-web document provides the language that it is using and it can be assumed that all of the text or user interface elements within that document will be using the same language unless it is indicated

<maryjom> Proposal 2:

<maryjom> When no other language has been specified for a phrase or passage of text, its human language is the default human language of the non-web document or software. So the human language of all content in single language non-web documents or software can be programmatically determined.

<maryjom> Proposal 3:

<maryjom> When no other language has been specified for a phrase or passage of text, its human language is the default human language as programmatically specified by the non-web document or software per success criterion 3.1.1. This means the human language of all content in single language non-web documents or software can be programmatically determined**,

<maryjom> which would satisfy the intent of this success criterion.**

The ** are markdowns , on determined and criterion, please ignore those.

These were supposed to be bold.

<maryjom> POLL: Which proposal do you prefer>

MaryJo: We will poll

Gregg: One of these says specified . Is a document that is all one language pass?

Gregg: Proposal 1 and 3 differ a lot on what is needed on marking up the document. 1 and 2 don't have explicit statement that you have to mark up the whole doc. Proposal 3 says programmatically specified.

Gregg: If you need to specify , you need to introduce it first rather than requiring. We don't want to say you have to but then later you don't need to.

MaryJo: What would you prefer?

Gregg: Prefer proposal one.

<maryjom> Inheritance is one common method. For example where the language of a non-web document as a whole is programmatically determinable, it can be assumed that all of the text or user interface elements within that document will be using the same language unless it is indicated.

Gregg: document as a whole can be programmatically determined.

Thanks.

Gregg: I was suggesting what Mary Jo just placed in.

MaryJo: You have to have basic knowledge of document.

Gregg: I was thinking language in total.

MaryJo: Perhaps putting commas in between as a whole.

Gregg: As a whole could be hard to translate.

<maryjom> Inheritance is one common method. For example, where the primary language of a non-web document is programmatically determinable, it can be assumed that all of the text or user interface elements within that document will be using the same language unless it is indicated.

MaryJo: Primary language of non-web document?

MaryJo: Any concerns with the change?

MaryJo: This would be an additional note here and update to EN to match.

<maryjom> DRAFT RESOLUTION: Update Proposal 1 in PR 714 as noted above, and add this new note to SC 3.1.2

<loicmn> +1

<ChrisLoiselle> +1

<bbailey> +1

<GreggVan> +1

<LauraM> +1

RESOLUTION: Update Proposal 1 in PR 714 as noted above, and add this new note to SC 3.1.2

Issue 691 - Differences between 2.1.1 keyboard guidance in WCAG2ICT and EN 301 549 content in clause 11.2.1.1 Keyboard

<maryjom> Link to issue 691: w3c/wcag2ict#691

<maryjom> Link to PR 718: w3c/wcag2ict#718

<maryjom> Proposed change to the PR: https://github.com/w3c/wcag2ict/pull/718/files#r2192868638

MaryJo: Shows deploy preview for Pull 718 for 2.1.1 keyboard

<maryjom> This is adjustment proposed for Proposal 3: Where ICT is or includes non-web software that can be run on a software platform that provides a device-independent keyboard interface service, this applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.1.

MaryJo: We agreed on note 1 on July 3rd.

We talked to issues about keystrokes.

MaryJo: I wanted to give people opportunity on wording if they had anything better for this term?

We will stick with keystrokes then. No objections.

<maryjom> Proposal 1: keep as is

<maryjom> NOTE 2: This success criterion does not imply that software always needs to directly support a keyboard or “keyboard interface”. Nor does it imply that software always needs to provide a virtual keyboard.

For Notes 2 and 3, Proposal 2 , pastes in text.

<maryjom> Proposal 2: What's in the EN draft

<maryjom> NOTE 2: This success criterion does not imply that software always needs to directly support a keyboard or “keyboard interface” if one is not provided by the platform software. But if one is provided, the software needs to make all functionality available through it - unless the exception applies.

<maryjom> NOTE 3: Nor does it imply that software always needs to provide its own virtual keyboard. But if it does, then it also needs to also support keyboard input from any keyboard interface provided by platform software.

<maryjom> Proposal 3: Some edits to the EN notes

<maryjom> NOTE 2: This success criterion does not imply that non-web software always needs to directly support a keyboard or “keyboard interface” if one is not provided by the platform software. But if one is provided, the software needs to make all functionality available through it - unless the exception applies.

<maryjom> NOTE 3: Nor does this success criterion imply that non-web software always needs to provide its own virtual keyboard. But if it does, then the software also needs to support keyboard input from any keyboard interface provided by the platform software.

Gregg: If we are changing from EN, we'd then advise EN that we are changing and want to align?

MaryJo: Yes, so we can come to resolution to send to you.

The only change on note 2 references This success criterion.

it is replaced with software

Gregg: From the keyboard interface . The software would have access to top piece of platform. I think intent is clear anyways.

<maryjom> POLL: Which proposal do you prefer?

<bbailey> 3 or 2 but okay with 1

<loicmn> 3, then 2

<GreggVan> 3

Gregg: Still instead of also may work better.

<maryjom> DRAFT RESOLUTION: To incorporate Proposal 3 in PR 718 into SC 2.1.1 as-updated in the meeting.

<GreggVan> +1

<loicmn> +1

<bbailey> +1

<ChrisLoiselle> +1

RESOLUTION: To incorporate Proposal 3 in PR 718 into SC 2.1.1 as-updated in the meeting.

<bbailey> +1

<Zakim> bbailey, you wanted to ask Gregg quick off topic question

Bruce: I can't be at input meeting , Gregg.

Issue 704: 1.4.4 Resize Text: EN 301 549 did not incorporate our updated notes

<maryjom> Link to issue 704: w3c/wcag2ict#704

PR 704 , will discuss next week.

MaryJo: We made changes to our notes. EN reverted back to 2013 version of note. Please review the issue to discuss next week.