– DRAFT –
WCAG2ICT Task Force Teleconference

<PhilDay> scribe:

Announcements

maryjom: Sent email regarding mobile TF work statement - as it doesn't appear to have been updated.
… Heard back that they will work on it.

Survey results: Review proposed updates to 2.4.2 Page Titled

Survey results: https://www.w3.org/wbs/55145/WCAG2ICTMay8/

[Chris sharing on screen]

<maryjom> https://www.w3.org/wbs/55145/WCAG2ICTMay8/results/#xq3

Decided on general structure of including headings (instead of using paranthetical callouts). Editors will handle this

Now focusing on 4. (Question 1 of 3) Non-web software - introductory info (before the SC language)

<bbailey> +1

1 prefers proposal 1 with edits, 4 prefer 2 as is

<bbailey> Proposal 1 does not provide a detailed explanation of why this is problematic - keeps it simple.

<bbailey> This should not be applied directly as written to non-web software. For software, direct application of 2.4.2 Page Titled is problematic. The following criterion is recommended as a substitute:

Proposal 2 provides a more detailed explanation.

This does not apply directly to non-web software through simple word substitution because application titles rarely describe the topic or purpose of the software. However, where the platform supports a programmatic title or name for a software window or screen, when a software application utilizes that feature to provide a unique title or name for

each window or screen, the user can more easily find it or understand its purpose. This would address the user needs identified in the Intent from Understanding Success Criterion 2.4.2

bbailey: Need to iterate on should not apply vs does not apply vs cannot be applied. This is my major concern - and could accept proposal 2 if this was addressed

GreggVan: What did we use in WCAG2ICT v1?

maryjom: Didn't need to - everything applied. This is a new issue.

Daniel preferred using "Cannot be applied" and then change "applies" to "Can apply" so they are all consistent.

<maryjom> Daniels PR to change "applies" to "can apply" w3c/wcag2ict#635

Daniel created a PR on this

GreggVan: Initially this sounded good, but could be interpreted as being rather vague.
… Does this apply? Answer should be yes or no, not "it could"

<maryjom> Here's issue 639 Daniel opened regarding can/cannot apply: w3c/wcag2ict#639

ChrisLoiselle: What we do in other SCs is more declarative. Can apply can be read different ways

GreggVan: Maybe opposite of Applies is "Does not apply"

<bbailey> i like current phrasing for the SC which work, "This applies directly as written"

<GreggVan> I note in choice 2 we already have "does not apply"

Daniel: My problems are with "shouldn't" or "doesn't" apply - this goes beyond our remit. Can/Cannot was an attempt to make the negative/positive more consistent
… Could live with "This applies directly as written", and then have inconsistencies for negative (Cannot be applied)

maryjom: Just use "is problematic to apply"

Daniel: Bruce had a sentence using similar language
… Combination of these 2 approaches could be good; using softer language for when something should not be applied

<ChrisLoiselle> w3c/wcag2ict#639

<ChrisLoiselle> w3c/wcag2ict#626

626 is Bruce's PR, which contains the sentence about "problematic"

<bbailey> Where known, give examples of some success criteria which may not be applicable to a particular

bbailey: This "problematic" language came from one of the TF meetings

GreggVan: If we say it applies, then the negative should just be "it does not apply".

<bbailey> Workstatement: https://www.w3.org/WAI/about/groups/task-forces/wcag2ict/work-statement/#scope-of-work

<maryjom> Maybe instead of saying, "does not apply" or "should not apply" use "This is problematic to apply to non-web software through simple word substitution"

maryjom: Proposing an alternative

<bbailey> non-web technology as needed./

<Zakim> bbailey, you wanted to discuss excerpt from work statement

<bbailey> Where known, give examples of some success criteria which may not be applicable to a particular non-web technology as needed.

bbailey: Pasted in the bullet from the work statement
… This uses "may not be applicable"

maryjom: When we do this for closed functionality we usually say why

GreggVan: Think we should say why here as well

Daniel: In 633 it says "does not directly apply... because rarely apply". So we contradict ourselves - rarely, not always, so sometimes it may apply.

<bbailey> "problematic to apply" seems like a fact-based statement to me

GreggVan: If you are taking this for a regulation, if something cannot be applied, then you cannot use it in a regulation. Here we are saying it is rarely possible; thus you cannot make it a regulation as it is rarely possible to meet. Thus not a contradiction.

ChrisLoiselle: Clarified why rarely was introduced in that SC

maryjom: Last time I proposed "problematic to apply". What do people think about it?

<Daniel> I would +1 "is problematic to apply"

bbailey: Agree - use problematic as we have used it elsewhere in the document. It is true - it is problematic

GreggVan: Thinking back to our purpose. If it is problematic, it is still not clear. Still leaves me wondering. Still need reasons why it is problematic.

ChrisLoiselle: Listening to where we are, We do already have an index of SCs that are problematic for closed functionality. Would it be useful to have another index of SCs that are problematic for X other reasons

<maryjom> Suggested first sentence: This success criterion is problematic to apply directly to non-web software through simple word substitution because application titles rarely describe the topic or purpose of the software and few applications could satisfy the criterion.

GreggVan: "There would be problems applying this to almost every software on the market". This is different to the closed functionality case - so defeats the purpose.

GreggVan: Just do this for individual SCs

Heading towards proposal 2 with edits.

<GreggVan> [07:28:59] <GreggVan> Q+ to say There would be problems applying this as a requirement for software for the following reasons OR becauwse

GreggVan: There would be problems applying this as a requirement for software for the following reasons; or, problems applying to software because.... Then we are not saying it does not apply, but just mentioning the reasons without making a categorical "not apply" statement.

<Zakim> GreggVan, you wanted to say There would be problems applying this as a requirement for the following reasons

GreggVan: Going to try and come up with a suitable phrase.

Consensus is to take proposal 2, PR 633 with edits, with edits to be decided later

Proposal 2 is PR 633

<ChrisLoiselle> Poll: Prefer Proposal 2, PR 633 , with edits, enter the number 1. Prefer Proposal 2, as is, (survey result answer that had 4 votes) , enter the number 2

<bbailey> https://deploy-preview-633--wcag2ict.netlify.app/#page-titled

1, but would also accept 2

<loicmn> 1

<ChrisLoiselle> Gregg, w3c/wcag2ict#633 would be the place to edit.

GreggVan: Questioned where to put proposed edit. maryjom: It is being done in a PR. 633

<bbailey> Verbage is in survey

GreggVan will put proposed language in IRC

<bbailey> Proposal 2 provides a more detailed explanation.

<bbailey> This does not apply directly to non-web software through simple word substitution because application titles rarely describe the topic or purpose of the software. However, where the platform supports a programmatic title or name for a software window or screen, when a software application utilizes that feature to provide a unique title or name for

<bbailey> each window or screen, the user can more easily find it or understand its purpose. This would address the user needs identified in the Intent from Understanding Success Criterion 2.4.2

<bbailey> Which approach do you prefer?

<bbailey> https://www.w3.org/wbs/55145/WCAG2ICTMay8/results/#xq3

<GreggVan> There would be problems applying this as a requirement for non-web software through simple word substitution because application titles rarely describe the topic or purpose of the software. However, where the platform supports a programmatic title or name for a software window or screen, when a software application utilizes that feature to provide a unique title or name for each window or screen, the user can more easily find it or

<GreggVan> understand its purpose. This would address the user needs identified in the Intent from Understanding Success Criterion 2.4.2. The following criterion is recommended as a substitute for the WCAG language:

<GreggVan> change only to There would be problems applying this as a requirement for non-web software

<GreggVan> change only This does not apply directly to non-web software to There would be problems applying this as a requirement for non-web software

<Zakim> bbailey, you wanted to suggest survey

Proposal 2 (original)

This does not apply directly to non-web software through simple word substitution because application titles rarely describe the topic or purpose of the software. However, where the platform supports a programmatic title or name for a software window or screen, when a software application utilizes that feature to provide a unique title or name for

each window or screen, the user can more easily find it or understand its purpose. This would address the user needs identified in the Intent from Understanding Success Criterion 2.4.2

Gregg's edit to proposal 2:

There would be problems applying this as a requirement for non-web software through simple word substitution because application titles rarely describe the topic or purpose of the software. However, where the platform supports a programmatic title or name for a software window or screen, when a software application utilizes that feature to provide

a unique title or name for

each window or screen, the user can more easily find it or understand its purpose. This would address the user needs identified in the Intent from Understanding Success Criterion 2.4.2

bbailey: Would prefer to put this in a survey.

GreggVan: Concern with problematic. We used it for closed, which meant we weren't dealing with it at all.

Daniel: In this case we would add the explanation - so we are providing the rationale

<bbailey> survey had 4/5 votes for proposal 2, and I was not one of them -- and greg was

<bbailey> https://www.w3.org/wbs/55145/WCAG2ICTMay8/results/#xq3

maryjom: Using the word problematic is not code for anything. All we say is that there is a problem. In this case we also give a solution, so am happy with the phrase problematic.

<Zakim> bbailey, you wanted to note survey had 4/5 votes

bbailey: We 4/5 that said proposal 2 was fine as is. Gregg was one of those who were happy with proposal 4. We seem to have stalled.

<Zakim> GreggVan, you wanted to say IF we want to go with problemmatic -- that is fine with me

GreggVan: We can change opinion after discussions.
… It is fine if others think that "problematic" works - I thought it was better to word it "there is a problem with". Either way is fine with me.

ChrisLoiselle: We will resurvey with 3 options: as was, with Gregg's edits, with Mary Jo & Daniel's edits, and option 4 will be other option (to be specified).

GreggVan: To move us forward let's just decide now

GreggVan: Happy to accept Mary Jo's edit to proposal if all others agree. Then we have consensus

bbailey: Also happy with it

Suggested first sentence: This success criterion is problematic to apply directly to non-web software through simple word substitution because application titles rarely describe the topic or purpose of the software and few applications could satisfy the criterion.

<maryjom> DRAFT RESOLUTION: Use proposal 2 introductory verbiage replacing "This should not be applied" with "This success criterion is problematic to apply".

<PhilDay> +1

<ChrisLoiselle> Poll: Accept Mary Jo's phrasing on introduction of problematic to apply phrasing

<bbailey> +1

<loicmn> +1

<ChrisLoiselle> +1

<Mike_Pluke> +1

<Daniel> +1

RESOLUTION: Use proposal 2 introductory verbiage replacing "This should not be applied" with "This success criterion is problematic to apply".

<GreggVan> +1

Moving on to next question.

(Question 2 of 3) Non-web Software - SC language

1 preferred proposal 1 as is, 3 preferred proposal 2 as is, 1 something else

<bbailey> https://www.w3.org/wbs/55145/WCAG2ICTMay8/results/#xq4

Proposal 1 language:

2.4.2 [Software Named]: [Non-web software] have names that provide description identification.

Proposal 2 language:

2.4.2 Non-web Software Named: In non-web software implemented on a platform that supports title attributes for windows or screens, titles are provided that are unique or differentiable within the software.

<bbailey> Now consider the proposed language for the success criterion in Proposals 1 and 2.

<bbailey> Proposal 1 language:

<bbailey> 2.4.2 [Software Named]: [Non-web software] have names that provide description identification.

<bbailey> Proposal 2 language:

<bbailey> 2.4.2 Non-web Software Named: In non-web software implemented on a platform that supports title attributes for windows or screens, titles are provided that are unique or differentiable within the software.

<bbailey> Which approach do you prefer?

GreggVan: Think I'm the other one, but agree with proposal 2, just adding comments

GreggVan: We cannot use proposal 1.

<Zakim> just, you wanted to repeat my comments in survey

bbailey: We could have both - as per my comments in the survey.

<Zakim> PhilDay, you wanted to say happy to go with consensus

<maryjom> +1 The short name should say "Titled" rather than "Named"

bbailey: Has a typo in it - short name is incorrect

<maryjom> Short name should be "2.4.2 Non-web Software Titled"

bbailey: short name should be "Titled" rather than change to "Named"

Mike_Pluke: don't like "provides descriptive information". Not sure what this really means

bbailey: description identification. Is used in WCAG 2

Mike_Pluke: Easier to understand in web. Software names makes it tricky

Daniel: Differentiable?
… Distinguishable? Is that better to use?

GreggVan: Distinguishable - you can perceive it. Differentiable means you can perceive the difference between them

GreggVan: Though we all agreed to number 2 - just need to work out short title

GreggVan: Non web software titled.

bbailey: Would accept proposal 2

<Zakim> PhilDay, you wanted to say happy to go with proposal 2

<maryjom> DRAFT RESOLUTION: Use proposal 2 substituting "Named" with "Titled" in the short name.

<loicmn> +1

<PhilDay> +1

<GreggVan> +1

<ChrisLoiselle> +1

<bbailey> +1

RESOLUTION: Use proposal 2 substituting "Named" with "Titled" in the short name.

<Mike_Pluke> +1

maryjom: Going to check the resolution on the previous issue

2 more questions to go over next week. (5, i.e. 3 of 3, then question 2 which we accidentally skipped)