– DRAFT –
WCAG2ICT Task Force Teleconference

<maryjom> Approve public comment responses - Issue 216

<maryjom> Survey results for remaining SC problematic for Closed Functionality content

https://github.com/w3c/wcag2ict/wiki/Work-for-the-week#preparation-for-the-14-march-meeting

Announcements

maryjom: We continue to chip away at work needed for next draft...
… include all the SC problematic for closed functionality
… that leaves 5 issues to resolve
… Tomorrow is a working session, trying to draft answers to open comments
… or maybe new edits and anything left over from today.

maryjom: Next week, including our Thursday, is CSUN...
… but meeting as usual.

Following week will be making decisions.

This week and next are working meetings , so drafting and clean up...
… including typos or editing notes.

After that, CFC to AGWG.

We are on track to publish 2nd public draft by end of April.

maryjom: Goal is for this to be penultimate version , assuming only minor feedback from AG review.
… also just note that Chuck is not available this week.

GreggV: HF group and TV looking at EN 301 549 this week.

Approve public comment responses - Issue 216

GreggV: That is why Mike Pluke is not available this week, and they will be considering closed products.

<maryjom> Link to response: w3c/wcag2ict#216 (comment)

<maryjom> Link to survey results: https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-public-responses-3/results#xq1

maryjom: I had some email correspondence with a few folks, but please see GitHub issue and Survey.

<maryjom> DRAFT RESOLUTION: Finalize the answer to issue 216, as-is

<PhilDay> +1

<olivia> +1

<Devanshu> +1

<mitch11> +1

<Bryan_Trogdon> +1

<ChrisLoiselle> +1

maryjom: No objections but we need the formal approval.

<FernandaBonnin> +1

RESOLUTION: Finalize the answer to issue 216, as-is.

Survey results for remaining SC problematic for Closed Functionality content

maryjom: Please be on look out for "response required" emails from me...
… looking for feedback in days between meetings.

<maryjom> Survey link: https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-SC-problematic-remaining-sc/results

SC Problematic for Closed Functionality – 4.1.2 Name, Role Value

<maryjom> Question link: https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-SC-problematic-remaining-sc/results#xq1

maryjom: Survey was a little late and only had 3 respondents as of last night.

<PhilDay> Google doc with discussion for 4.1.2: https://docs.google.com/document/d/1wNs7-XobyZiBBnSH-85nLg6FXTK4okTdzHOLE_Jp4kw/edit#heading=h.o93vreyuxdat

[mary jo shares screen, from survey results]

[and linked google docs]

maryjom: Cues in Google doc more explicit this time around.

GreggVan: We should at top of section of closed products that they have problem with working with some or all AT...
… they all depend on programmatically determinable so equivalent functionality needs to be provided...
… its about the same text for each of these SC

PhilDay: We might write about the features and functionality relevant to each SC...
… favor a longer approach

GreggVan: Normally I would agree, but I think we are on the cusp of having a lot of coga oriented AT, so every single disability potentially has AT available....
… We can we go with this given so many needs are impacted. Approach from 20 years ago , where we ask questions like "can a blind individual use this" is not suffiecient.

<maryjom> Poll: 1) Leave text as-is, 2) Incorporate Option 5 as-is, or 3) Something else.

<mitch11> 3

<GreggVan> 1

<PhilDay> 2

<ChrisLoiselle> 2

<FernandaBonnin> 2

mitch11: I think Gregg's suggest excellent. I can support 2, but slightly better would be 1 with ...

<GreggVan> +1 to that

mitch11: 1 provided the information in 2 is at section at top.

<mitch11> +1

GreggVan: Agreed, we would take what is in 2 and move to top of section.

<mitch11> oops I mean q+

<Zakim> PhilDay, you wanted to invite Bruce to talk to "Requires" as per his survey

maryjom: I am not sure if say something like this else where.

PhilDay: Bruce talked aobut requires on survey

<Zakim> bruce_bailey, you wanted to talk about "requires"

mitch11: If we agree information "like in 2" is the general idea, then take editorial pass.

bruce_bailey: Comment about requires fits into Gregg & Mitch's comments - address the gap in programmatically determined. Makes sense to move it to the top of the section rather than doing it individually

maryjom: Jumping to Bruce's comments in survey on "Requires"

bruce: use of "requires" is problematic when we mean its a prerequisite or condition for the SC to be able to meet.

<ChrisLoiselle> for reference, https://www.section508.gov/content/glossary/#:~:text=Programmatically%20determinable%3A%20Ability%20of%20software,to%20users%20in%20different%20modalities and https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#programmaticallydetermineddef

bruce: also that fits with moving the collection of comments to one place in the doc.

maryjom: That is how WCAG2ICT v1 did it.

bruce_bailey: WCAG2ICT - first iteration may not be the best example - use of "requires" in earlier edition was a mistake in my opinion.

<maryjom> https://www.w3.org/TR/wcag2ict/#closed_functionality_sc

bruce_bailey: want to remove the use require as it is a trigger word like should or shall.

GreggVan: But it is a requirement - so use of require is appropriate

Bruce: thinks it an error that the section of WCAG2ICT using "requires" is poor

GreggV: Section is restating SC requirement, so thats fine.

Bruce: For 1.1.1 use of "require" is fine. But with 1.31. requires does not paraphrase the success criterion

maryjom: We have made some improvements along this line.

GreggVan: Happy to use requires where we are paraphrasing the requirement

PhilDay: Think we are getting too off track and in the weeds.

GreggV: "requires" where it means "requirements" is okay.

maryjom: We have reviewed this before

GreggVan: We do need to come back if there are mistakes

bruce_bailey: Still not comfortable on use of word Requires. Need an editorial pass to ensure every use of "requires" is a paraphrase of requirement from an SC, and nothing else

Bruce: I think we need to do a pass on how we use "requires".

https://w3c.github.io/wcag2ict/#success-criteria-problematic-for-closed-functionality

Link above is the latest editor's draft.

maryjom: 2013 version was not consistant on this point, but be sure to be looking at current editorial draft

https://w3c.github.io/wcag2ict (to go to top for search)

maryjom: There has not been any issues opened on these past years, so I presume we are okay using previous text.

<mitch11> Proposal to address Bruce's concern: Conformance to this success criterion requires

maryjom: What we may want to consense on is keeping "as is" but capturing the detailed information elsewhere]
… is that where we are going

maryjom: If you disagree, please get on queue

PhilDay: I am okay with general direction, but that we ALSO need to step through SC.

Option 0 - Original content in existing editor’s draft 4.1.2 Name, Role, Value—requires information in a programmatically determinable form.

maryjom: Any objections to Option 0 then ?

General statement to add to start of SC problematic for closed Requires information in a programmatically determinable form. Where this is not possible, providing equivalent information and operation through another mechanism, such as functions built into the software that behave like assistive technology, would help meet the intent of this success criterion.

mitch11: I am less concerned , but since bruce scribing hard for him to experess concerns

Bruce: Sounds good to me.

<maryjom> DRAFT RESOLUTION: Keep text as-is (Option 0) for Name, Role, Value in the SC Problematic for Closed Functionality section, and add Option 5's additional text to the introductory paragraph of the section..

+1

<FernandaBonnin> +1

<mitch11> +1

<olivia> +1

<ChrisLoiselle> +1

bruce_bailey: Name/role/value - requires - shorthand for why it is problematic, not restating the SC

RESOLUTION: Keep text as-is (Option 0) for Name, Role, Value in the SC Problematic for Closed Functionality section, and add Option 5's additional text to the introductory paragraph of the section..

bruce_bailey: Requires: using in 2 different ways: sometimes to restate the SC, sometimes to state why something is problematic. We need to be clearer in the language

1.3.1

SC Problematic for Closed Functionality – 1.3.1 Info and Relationships

Latest content: w3c/wcag2ict#275 (comment)

<maryjom> Question link: https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-SC-problematic-remaining-sc/results#xq2

maryjom: from survey, 3 votes for "as-is"

maryjom: any concerns for same approach?

+1 to do the same as before with 1.3.1

<ChrisLoiselle> +1

<maryjom> DRAFT RESOLUTION: Keep text as-is (Option 0) for Info and Relationships in the SC Problematic for Closed Functionality section, and add Option 5's additional text to the introductory paragraph of the section..

<ChrisLoiselle> +1

+1

<Devanshu> +1

mitch11: Options in survey and from call, option 0 means different things?

maryjom: Question is if we can approach the same?

mitch11: Then are NOT the same exact wording.

Option 0: Current content in the editor's draft 1.3.1 Info and Relationships — Requires information in a programmatically determinable form.

Option 1: Latest proposed content for SC problematic for Closed functionality section 1.3.1 Info and Relationships—Requires information in a programmatically determinable form or in text. Where this is not possible, providing equivalent information and operation through another mechanism, such as functions built into the software that behave like assistive technology, would help meet the intent of this success criterion.

<maryjom> Poll: Use 1) Keep Option 0 text, 2) Use first sentence of Option 1, or 3) something else

maryjom: Okay, agreed. But we have consensus on the general approach.

<mitch11> 1 or 2

maryjom: this is just about bullet.

2, but also happy with 1

<olivia> 2

maryjom: I put more into the text because I was reading the SC.

mitch11: I still have preference for Option 0 / Option 1 because is explict that programatic text is the issue

GreggVan: I like option 3 (option 0, requiring programatically available text)

maryjom: Okay, I think I have the edit.

Option 3: Gregg change Requires information in a programmatically determinable form or in text (that is programmatically determinable)

GreggVan: I did a "requires" pass to the listserv

<maryjom> Poll: Use 1) Keep Option 0 text, 2) Use first sentence of Option 1, or 3) Option 3 - above

mitch11: WCAG does not link to definition of text in 1.3.1

maryjom: I have done a pull request to that effect

GreggVan: link should not be normative

bruce: i remember that conversation

mitch11: And its complicated with Greggs Option 3

bruce_bailey: Remembers the conversation: should link to the defined term, then it ended in disagreement, so it was left ambiguous.

mitch11: all the options are okay

bruce: my recollection is that AG decided that use of "text" is deliberately ambiguous

<maryjom> Poll: Use 1) Keep Option 0 text, 2) Use first sentence of Option 1, or 3) Option 3 - above

3, 2, then 1, but happy with them all

<mitch11> 1, then 2, then 3

maryjom: option 3 is greggs edit

<GreggVan> 3 or 1

<ChrisLoiselle> 3 , i think

<mitch11> I accept (smile)

RESOLUTION: Use text in Option 3 (Gregg's edit above) for Info and Relationships in the SC Problematic for Closed Functionality section, and add Option 1's additional text to the introductory paragraph of the section.

maryjom: We have two of five.

SCs Problematic for Closed: 2.4.4 Link Purpose (In Context)

<mitch11> I just struggle to talk

maryjom: this should be quick

maryjom: survey votes 3 for as-is

Proposed content: w3c/wcag2ict#274 (comment)

maryjom: except bruce's concern for "requires"

maryjom: I think we better stop. Remaining questions and survey results tomorrow.

reminder about time zone1