W3C

– DRAFT –
WCAG2ICT Task Force Teleconference

27 July 2023

Attendees

Present
bruce_bailey, Bryan_Trogdon, ChrisLoiselle, Devanshu, FernandaBonnin, LauraBMiller, loicmn, loicmn_, maryjom, mitch, mitch11, olivia_, PhilDay, Sam, shadi, ThorstenKatzmann
Regrets
Shawn Thompson
Chair
Mary Jo Mueller
Scribe
mitch11

Meeting minutes

<PhilDay> https://github.com/w3c/wcag2ict/wiki/Scribe-list-&-instructions

<LauraBMiller> https://github.com/w3c/wcag2ict/wiki/IRC-information

Announcements

finished 3rd content review, 5 criteria

substantive feedback included on CSS pixel definition

<maryjom> https://github.com/w3c/wcag2ict/pull/199/files

editors notes are in a pull request

@chuck CFC ends tuesday

<Chuck> s /CFC/pre-CFC/

maryjom: cfc got feedback on 5 criteria
… please vote as well

Devanshu: when will first public working draft be?

maryjom: if all is smooth then 2 weeks from today, otherwise the tuesday after

bruce_bailey: current version of editor's draft should be easy to fine, while historical version available, how to do this?

Chuck: public is marked public, draft is marked draft, asking to clarify 'easy to find'

bruce_bailey: type a predictable URL

maryjom: W3C has a registry of published docs; old version will remain there
… link to registry from the doc itself

maryjom: we can make sure the Task Force page has links

<Chuck> mitch: You said one of the two things was link from TF. Can the old document link to the new one?

mitch11: can old doc link to new one?

<ChrisLoiselle> https://www.w3.org/WAI/GL/task-forces/wcag2ict/#publications

maryjom: yes once it's finalized

<Zakim> Chuck, you wanted to say I don't think so. and to say 'yet'

Chuck: inappropriate for a published doc to point to a draft
… down the road we'll follow w3c processes

<bruce_bailey> The URL that I hope is at top of ED et al. is: https://www.w3.org/TR/2013/NOTE-wcag2ict-20130905/

CfC to publish the First Public Working Draft

maryjom: AG WG review was going well, in the meeting did a pre-CFC
… also this TF should decide if we agree
… that the current editor's draft should go forward

<Chuck> proposed RESOLUTION: WCAG2ICT TF supports the publishing of the FPWD

<bruce_bailey> The URL that I hope is towards beginning of FCPWD is: https://www.w3.org/TR/2013/NOTE-wcag2ict-20130905/

Chuck: what should have happened is the Task Force resolution to support publishing of 1st public working draft
… now we should do it after the fact
… in future, it should be a resolution before going to agwg

<maryjom> proposed RESOLUTION: WCAG2ICT TF supports the publishing of the FPWD

<bruce_bailey> +1

+1

<loicmn> +1

<PhilDay> +1

<Bryan_Trogdon> +1

<ThorstenKatzmann> +1

<Devanshu> +1

<ChrisLoiselle> +1

<shadi> +1

<Chuck> sam +1

<maryjom> +1

RESOLUTION: WCAG2ICT TF supports the publishing of the FPWD

<LauraBMiller> +1

Survey Results: Review draft updates to SC Problematic for Closed Functionality

maryjom: since this is going to public draft, she won't merge content into it until it goes out

Chuck: not speaking as a GitHub guru: we don't want to change the version going to AGWG and public. But we could branch for future versions.

<PhilDay> Is this prepCFC draft the latest definitive version for review: https://deploy-preview-199--wcag2ict.netlify.app/

maryjom: question about not wanting to break the W3C publishing flow, for Daniel, maryjo will ask him Monday

PhilDay: I'm also confused. Yes important not to break. We could document things with PRs
… is "199" URL correct for pre-CFC?

maryjom: yes

bruce_bailey: we also could do PRs and mark them as draft. It's nice to make PRs as we go, keep it moving

maryjom: agreed want not to slow down

<maryjom> https://www.w3.org/2002/09/wbs/55145/wcag2ict-sc-problematic-for-closed/results

Survey Results

maryjom: On to the survey on closed functionality
… Now 2.4.5 Motion Actuation is the only one with no comments

<maryjom> Draft RESOLUTION: Incorporate the proposed updates for the above list of SC as-is.

<loicmn> +1

<PhilDay> +1

+1

<ThorstenKatzmann> +1

<maryjom> +1

<FernandaBonnin> +1

<PhilDay> sam: +1

<olivia_> +1

<bruce_bailey> +1

RESOLUTION: Incorporate the proposed updates for the above list of SC as-is.

maryjom: introduction section

Question 1 - Review proposal for the Introductory paragraph

bruce_bailey: are the changes we're discussing today not for the publication?

maryjom: correct
… demo of "preview" link in GitHub for a PR

PhilDay: also have feedback from his colleagues, can wwait

maryjom: summarizing the survey results for this topic

<bruce_bailey> good catch that "closed functionality" not an intuitive term !

maryjom: agree with Bruce that 'closed functionality' not an intuitive term
… it is mentioned earlier in the same document, but not a definition

<ChrisLoiselle> +1 to Mitch's terminology update on the definition

bruce_bailey: we could say: can't attach AT
… get in the habit of that

<bruce_bailey> thank you phil for talking with sw developers !

PhilDay: software folks who would need to interpret it, understanding that some SCs are problematic, but not clear whether that means they're optional or not applicable or automatically fail

maryjom: unless the audience is other standards orgs

<Chuck> mitch: I agree that standards orgs are one of the audiences, evaluators that do audits would look at prior version. But prior to that, it would be useful to go through more of the topics from the questions and then come back to Phill's question.

<Chuck> mitch: We can review how much we may have already solved.

<Zakim> bruce_bailey, you wanted to say i presumed sw developer are our audience

bruce_bailey: also agree WCAG2ICT has a software developers audience

<maryjom> o Poll: Which option do you prefer? 1) Option 1 – use “screen readers”, 2) Option 2 – use “assistive technology”, 3) Option 3 - use “closed functionality”, or 4) Something else

<PhilDay> 3, with a definition as per next set of questions!

<maryjom> Option 1: As an example, Success Criterion 2.1.1 Keyboard would apply to systems which are closed to screen readers, but have a physical keyboard or a connector for standard keyboards.

<maryjom> Option 2 – Edit sentence with the example using “are closed to assistive technologies”: As an example, Success Criterion 2.1.1 Keyboard would apply to systems which are closed to assistive technologies, but have a physical keyboard or a connector for standard keyboards.

<maryjom> Option 3 – Edit sentence with example using “have closed functionality”: As an example, Success Criterion 2.1.1 Keyboard would apply to systems which have closed functionality, but have a physical keyboard or a connector for standard keyboards.

<FernandaBonnin> 3, with definition

<ChrisLoiselle> 3

<olivia_> Option 3

4: closed to assistive technology software

<Bryan_Trogdon> 3

<PhilDay> 3, with definition

<ThorstenKatzmann> 3

<loicmn_> 3

<LauraBMiller> 3 with definition that includes screen reader as an example.

<Chuck> mitch: Option 4 is something else, and that is an alternative I'm offering. I concede to 3.

<maryjom> Option 1 - Add at the top of the Appendix on closed functionality the following: “Closed functionality" prevents users from attaching, installing, or using their own assistive technology. To support users with disabilities, products with closed functionality can instead provide built-in features that act as assistive technology

maryjom: how to say what 'closed functionality' means - presenting options

<maryjom> Option 2 – Leave as is (don’t add) REASONING: Section 3. Closed Functionality has similar text already, quoted below.

<maryjom> Option 3 – Add key term “closed functionality” using 508’s definition and reference it Characteristics that limit functionality or prevent a user from attaching or installing assistive technology. Examples of ICT with closed functionality are self-service machines, information kiosks, set-top boxes, fax machines, calculators, and computers that are locked down so that users may not adjust settings due to a policy such as Desktop Core [CUT]

<maryjom> Option 4 – Add key term “closed functionality” using EN 301 549 definition & reference it functionality that is limited by characteristics that prevent a user from attaching, installing or using assistive technology

<Chuck> mitch: For option 2, its quoted from somewhere, where is that quoted from?

Chuck: when we reference content outside our org (chair hat off), careful for what is source of truth, what happens if it changes in the future. Question: are we will to confer expertise on the definition, even if a future update occurs?

<Zakim> bruce_bailey, you wanted to note that "examples of products with closed functionality" could be more plain language

bruce_bailey: as Task Force we should be able to say what the term means
… the section shown could also say can't attach AT

<Zakim> PhilDay, you wanted to say Can we incorporate the definition rather than linking a reference?

PhilDay: agree with having a definition
… can we reproduce it?

<Chuck> mitch: Reproducing it, it's my intention. EN had the word "or using". In short I think we can draft our version of it. It's not the definition for all the world for all time.

LauraBMiller: and see Canadian CSA standard for their definition
… be more inclusive not US centric

<Zakim> Chuck, you wanted to say I don't now about that, worth exploring

Chuck: don't know if they've done something with owning the definition, can speak with W3C

maryjom: or a variation that isn't a direct quote
… with chair hat off, in favor of providing our definition

<PhilDay> PhilDay: Quote from CSA B651.2 (22): T his Standard specifies minimum accessibility requirements for self-service interactive devices (such as, but not limited to, automated banking machines, retail self-checkout, self check­ in devices, ticket vending kiosks, smart card sales, query and reload devices).

Sam: pro having our own definition not referencing EN 301 549, things change in the EN more frequently

<PhilDay> PhilDay: CSA does not define what is meant by closed functionality (or I can't find it!)

Bryan_Trogdon: support making it less fragile; support the definition

FernandaBonnin: Like the definition. Want examples too, like option 3

<Zakim> PhilDay, you wanted to say CSA does not define closed functionality from my quick search

PhilDay: looking at CSA (Canada) - it scopes the standard as self-service interactive devices with examples, but does not define our term

<Zakim> bruce_bailey, you wanted to say +1 on definition -- but then try not to use in prose !

PhilDay: we could include their examples
… CSA is a Canadian Standards organization

bruce_bailey: we can use section heading, then repeat a phrase
… we need it as a key term, yet avoid using it where we can, we can say it differently

maryjom: but we have sections that use the term already

LauraBMiller: agreed with Phil the CSA standard doesn't use the term
… but they talk about what people with disabilities need for interacting with systems

<Zakim> Sam, you wanted to bruce comment.

LauraBMiller: not just for blindness, also people who are deaf for example

Sam: not hearing objection to having a definition, a key term
… but also hearing hesitations about referencing or using verbatim
… agreeing and advocating

<Zakim> PhilDay, you wanted to say If we don't use a defined term liked closed functionality in the text, we may end up with longer sentences

<Zakim> LauraBMiller, you wanted to say agree, using a key term with examples or definition.

PhilDay: agree we should use plain language, but the phrase could get longer, could become tedious to read. So open to it if someone can suggest a phrase

<bruce_bailey> i agree w/ phil that it might be tricky to avoid in prose

LauraBMiller: yes should explain the term
… in something like a definition

<maryjom> Poll: Should we develop a key term "closed functionality" and put in Key terms section with examples? 1) Yes or 2) No

<FernandaBonnin> 1

<loicmn_> 1

<PhilDay> 1

<Bryan_Trogdon> 1

<bruce_bailey> 1

<Devanshu> 1

<LauraBMiller> 1

<Sam> 1

1

<olivia_> 1

maryjom: will draft based on Mitchell's and we can review
… expect it may take a while, lively discussion, everybody's input appreciated

Summary of resolutions

  1. WCAG2ICT TF supports the publishing of the FPWD
  2. Incorporate the proposed updates for the above list of SC as-is.
Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).

Diagnostics

Succeeded: s/will also have/also have/

Succeeded: s/dev/definition/

Maybe present: 4, Chuck

All speakers: 4, bruce_bailey, Bryan_Trogdon, Chuck, Devanshu, FernandaBonnin, LauraBMiller, maryjom, mitch11, PhilDay, Sam

Active on IRC: bruce_bailey, Bryan_Trogdon, ChrisLoiselle, Chuck, Devanshu, FernandaBonnin, LauraBMiller, loicmn, loicmn_, maryjom, mitch11, olivia_, PhilDay, Sam, shadi, ThorstenKatzmann