– DRAFT –
WCAG2ICT Task Force Teleconference

<dmontalvo> e

Announcements

maryjom: Request update from Chuck on WCAG 2.2

Chuck: Still dealing with 2 formal objections, but momentum is positive. Incorporating Deque comments so should resolve that one. Another one on internationalisation - working with objectors
… So hoping just be a few days late - publish early September
… But timings depend on how it goes

<Zakim> shadi, you wanted to ask about commenting deadline for FPWD

<Zakim> bruce_bailey, you wanted to ask if these two formal objections are public facing ?

bruce_bailey: Are objections public facing?

Chuck: Believes they are public and can provide details offline if needed

<bruce_bailey> thank you

<shadi> https://www.w3.org/2002/09/wbs/33280/2023-07_PR_WCAG22/results

shadi: Not sure if all have access to the discussion

shadi: Question was different. On first public draft, what is the commenting deadline for WCAG2ICT?

<bruce_bailey> i get "not allowed" but no problem and not unexpected

shadi: Looks like we forgot to put a time on when to put comments out.

maryjom: Usually it is 30 days from publication

<Chuck> "oops"

shadi: Given the importance of this doc, suggest it is 4 weeks

maryjom: so Roughly 15th September

maryjom: Also missing some details on how to make comments

PhilDay: I wonder if we should make it 4 weeks from when we publish from when we state there's a deadline. Just to give people enough time.

MaryJo: I don't think it's unreasonable. I'll get with Daniel and Shawn to make the adjustments.

bruce_bailey: Does it matter? Anyone can file an issue at any time.

<Zakim> bruce_bailey, you wanted to say anyone can file issue any time

maryjom: Correct, but having a deadline gives some impetus

shadi: Agree with usefulness of deadline

Chuck: Concur that it doesn't matter, so agree with 4 weeks from "now" not from 15 Aug

<bruce_bailey> i had thought that not having due date was a choice

maryjom: Other thing to bring up

It would be nice to claim it was a strategy. It was an "oops".

maryjom: because of link address that was used, it broke links to the older document, so these links from our document do not currently work. Still to be fully resolved.
… However it does mean that EN and others will point to the new document

dmontalvo: Given we are working on how we can fix the link issue - will update the group on how to fix that problem to still be able to refer to the old document. Deadline can be added to the communication

bruce_bailey: All for a nice URL going to our draft, but concerned with a big red banner saying it is deprecated when it is not yet (until ours is fully published).

dmontalvo: Agree we need to work on this, but it may take a while to reverse

<bruce_bailey> i am all for making people work a little hard to turn up older version

maryjom: Has created an issue on links and banners and will assign to the correct people

maryjom: Positive is that the draft is out there and being reviewed.

dmontalvo: We haven't modified anything from the 2013 content - we've just added additional 2.2 content.

<Zakim> bruce_bailey, you wanted to say please dont have default url point to 2013 version

bruce_bailey: It was a deliberate choice for the short URL to point to the new draft. We just need to fix the warning, and ensure there is a way to reference the old 2013 version.

<bruce_bailey> https://www.w3.org/TR/2013/NOTE-wcag2ict-20130905/

maryjom: Finding the older document is not linked at the top - you need to dig down into the content a bit of the new public draft content to find it.

<bruce_bailey> From U.S. 508 perspective, having the short URL point to working draft is not problematic.

maryjom: Since we are now getting public comments, I was looking for a process on how to review

<Zakim> Chuck, you wanted to review the "process"

FPWD public comments

Chuck: Mary Jo asked if there was a documented process for handling comments. AGWG has been doing it without a documented process, so asks for WCAG2ICT to follow the unofficial process.
… Through whatever mechanism we get a comment, we create a GitHub issue, we work it, then reply in the GitHub issue and also send a copy back to the commenter in whichever mechanism they used.

GitHub issue is labelled as DRAFT RESPONSE, group reviews response, then comes to a formal resolution. Then issue changes to FORMAL RESPONSE, is sent via GitHub and whatever communication platform they used to submit

<maryjom> https://github.com/w3c/wcag2ict/wiki/Process-for-addressing-public-comments

<bruce_bailey> it is so good!

maryjom: Has already drafted something for review to get us started

<bruce_bailey> Link was in M Jo email 8/22.

maryjom: Believe that the link above matches Chuck's description. Review and comment.

<Zakim> bruce_bailey, you wanted to suggest adding disscussion

maryjom: Happy to update if it is unclear. Tried to add in timeline to help clarify and ensure timely response

bruce_bailey: Timeline is very aggressive - good aim, but might be lots of work. For issues that are filed that have multiple comments, convert into discussions so they are threaded

<Zakim> PhilDay, you wanted to ask if this captures Bruce's suggestion

<maryjom> https://lists.w3.org/Archives/Public/public-wcag2ict-comments/2023Aug/0000.html

maryjom: Now talking about the comment that we have received - see link from maryjom

<maryjom> Link to issue for response draft: w3c/wcag2ict#215

maryjom: Issue has been created with draft response. There has been some discussion in the thread, now ready to discuss with the full task force.

<Zakim> Chuck, you wanted to offer philosophical thoughts on replying to public comments

Chuck: Offers some chair advice. Inspired by this comment, but not looked at detail of the response.
… First: Chuck's advice. There were 2 specific critiques; one on the group makeup, other on the document. We had asked for comment on the document, not on the group.
… Part of why we go to public comment is to get better representation - and if there is a lot of comment on a particular sector it is appropriate to invite others from that sector.
… We should focus discussion now on the document, and consider representation separately
… Rachelle's comment: What we are looking for is actionable suggestions. This comment was rather vague - so we could try and tease out more specific recommendations.
… Hope is to get actionable, tangible changes, not vague high-level comments.

maryjom: [sharing screen on proposed response]

<Zakim> bruce_bailey, you wanted to see if L B on call?

<bruce_bailey> i will also mention that i was a little uncomfortable that the offline email took so much time to get converted to GitHub issue

bruce_bailey: Checking if we had anyone from TPG on. Proposed response is good. There was too much non-public discussion so it is good that we now have the process to use GitHub.

<bruce_bailey> +1 for proposed response

<bruce_bailey> also thank you Chuck for that over view -- i meant to say with my voice

Chuck: Rochelle & I did not look at this response in giving suggestions, but this nails it perfectly. No suggestions on improvements.
… What did Bruce mean by the private discussion, and does the process resolve it?

bruce_bailey: We didn't have a process, so we had some offline discussion in email between Phil, Laura & Bruce, so this has now been resolved with the new process of having all responses to comments in GitHub.

<bruce_bailey> yes, i also agree with people going off line

Chuck: 3 individuals working on a response is fine - just making sure it is on GitHub so in the public domain

<maryjom> DRAFT RESOLUTION: Send response on kiosk comment received on 15 August, as proposed.

+1 from Chuck as Oracle (no chair hat)

<maryjom> DRAFT RESOLUTION: Send response on kiosk comment received on 15 August, as proposed in issue 215.

maryjom: Proposed content is in issue w3c/wcag2ict#215

<Sam> +1

<maryjom> +1

<Devanshu> +1

<bruce_bailey> +1

+1

<olivia> +1

<ShawnT> +1

<bruce_bailey> thanks Phil !

RESOLUTION: Send response on kiosk comment received on 15 August, as proposed in issue 215.

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

<GreggVan> +1

1.4.12 Text spacing

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

maryjom: Gives link to survey results
… and link to discussion from last week

<maryjom> discussion from last week: https://www.w3.org/2023/08/17-wcag2ict-minutes#t04

maryjom: Recap - there were some editorial changes, but also some more substantive input from Mike Pluke - mentioning markup language doesn't seem to fit. Also thought this SC could apply more broadly

maryjom: Then looked at other SCs and found an inconsistency in how we handle markup language. Other places included Status Messages, and Text Spacing SCs.

In Status Messages, we added some more guidance - so it was broader than just markup language.
… So we may need to change our guidance on Text Spacing

So refer to code/software or markup languages, rather than just referring to markup languages
… That is a way forward, and makes the potential content for Closed Functionality to be a little easier to think about.

<maryjom> Option 4 – edit removing “markup” Closed functionality software rarely supports user modification of line, paragraph, letter or word spacing. In such infrequent cases the SC applies as noted in the Guidance on Applying Success Criterion 1.4.12 to Non-Web Documents and Software.

<Zakim> GreggVan, you wanted to say "we should avoid the term "no need to" -- that inadvertently denies a person needs. We are supposed to say if it applies or not -- not whether we think anyone has a need for this.

GreggVan: Instead of saying whether it applies, we have stated if there is a need which is a bit unhelpful. We should talk about applicability, not need.

Chuck: Don't have to overly rely on our process, but could this be raised as a public comment as it was observed in the public draft, and then discussion is in the public domain.

<Zakim> bruce_bailey, you wanted to say that *not* constraining WCAG2ICT guidance to "technology using markup language" would be helpful.

maryjom: Yes, that is my intent - can be a separate comment

bruce_bailey: Like the idea of it being a separate discussion, as guidance should not be constrained just to technology using markup language.
… but it does take us close to out of the scope. It's straightforward to apply the current SC (content implemented using markup language), but it is good to interpret more broadly

GreggVan: Apologies for absence. This is interesting - this is about the content on the closed product. If the closed product has the ability to change these things (like text spacing) then it should.
… We are not requiring that a user agent support or provide the functionality, but if it does provide them, then the SC should apply to the content.
… How do we differentiate between content and markup languages? Could be confusing

maryjom: [sharing guidance on status messages]

<maryjom> https://w3c.github.io/wcag2ict/#guidance-when-applying-success-criterion-4-1-3-to-non-web-documents-and-software

<maryjom> Link above is what we have in WCAG2ICT for 4.1.3 status messages

maryjom: We added in "or that supports status message notifications" to "content implemented using markup languages" to give broader coverage in software.
… But this made us inconsistent with Text spacing SC

In Text Spacing we just left it as "content implemented using markup languages".
… So Mary Jo will open an issue to flag this inconsistency, and will add proposals for resolution to the issue.

<bruce_bailey> good catch @maryjom that we are not wholly consistent

GreggVan: Where are the options?

maryjom: One was in a survey, then the others arose from the meeting discussions over the last 2 weeks.

<bruce_bailey> i like option 4

<maryjom> o Poll: Which do you prefer? 1) Option 1 – as proposed, 2) Option 2 – with edits, 3) Option 3 – edit from last meeting, 4) edit removing “markup”, or 5) Something else

4

<olivia> 4

(but OK with 3 if others prefer it)

<GreggVan> 4 but remove the last infrequent

<bruce_bailey> and it applies even when not implemented in markup languages

4 (from Oracle, no chair hat)

<ShawnT> 4

GreggVan: you say rarely supports. Remove in such infrequent cases, and replace with Where the software supports it...

Closed functionality software rarely supports user modification of ... In closed functionality software where any of these are supported, the SC applies ...

<maryjom> Add phrase: If closed functionality software supports any of these modifications,

<Sam> I am not in agreement with all of Gregs comment

GreggVan: Remove the word any

<bruce_bailey> @gregg, yes the iPhone being closed functionality is interesting discussion

maryjom: Will continue this next week. Apologies to Sam for being on the queue - please write it down in the issue and we can discuss next week.