– DRAFT –
WCAG2ICT Task Force Teleconference

Announcements

<maryjom> https://github.com/w3c/wcag2ict/wiki/Work-left-for-second-public-draft

Maryjom - for announcements we are working through and all content is in the editors draft. Document is up to date. We finished everything in the first table

Maryjom, starting to move the completed items to the bottom of the table.

Maryjom: hoping to have few changes when it goes out for review. As soon as you can, take up an item or get your item done and let me know when it is ready to be discussed.

Maryjom - there may or may not be a survey this week. We have a few SCs to work on tomorrow. Text spacing and reflow.

Survey results - Review of 4.1.3 Status Messages proposal

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-Status-Messages-update/results

SC 4.1.3: Word substitution language

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-Status-Messages-update/results

<maryjom> Option 1 – 4.1.3 taken literally: https://docs.google.com/document/d/1ejuKX3cq06b3MY48h2wJPHJXfFYJLIjI0rUNf3PfoJQ/edit?usp=sharing

<maryjom> Option 2 – 4.1.3 Contextualized: https://docs.google.com/document/d/1ejuKX3cq06b3MY48h2wJPHJXfFYJLIjI0rUNf3PfoJQ/edit#heading=h.71h05lkcix1x

Two options for the main guidance we are reviewing. Option 1. 4.1.3 taken literally. Option 2 was a contextualized version

Split vote.

<Zakim> bruce_bailey, you wanted to ask why people liked option 2

<maryjom> Poll: Which option do you prefer? 1) Option 1, 2) Option 2, 3) Something else

<PhilDay> 1, but also accept 2

<mitch11> 1, also accept 2

<loicmn> 2, but also accept 1

<Chuck> 1, either is fine

<olivia> 1, but also accept 2

<bruce_bailey> 1 but also accept 2

Either is fine

Maryjom: looks like we are settling on option 1. Incorporate the word substitution as is in option 1

<maryjom> DRAFT RESOLUTION: Incorporate the word substitution Option 1 as-is for SC 4.1.3.

<loicmn> +1

<PhilDay> Applying SC 4.1.3 Status Messages to Non-Web Documents and Software This applies directly as written, and as described in Intent from Understanding Success Criterion 4.1.3 (also provided below) without word substitution.

<Chuck> +1

<PhilDay> +1

<bruce_bailey> +1

<mitch11> -1

<FernandaBonnin> +1

<bruce_bailey> good catch mitch !

<mitch11> +1

<PhilDay> Option 1: Applying SC 4.1.3 Status Messages to Non-Web Documents and Software This applies directly as written, and as described in Intent from Understanding Success Criterion 4.1.3 (also provided below) without word substitution.

RESOLUTION: Incorporate the word substitution (which is really no word substitution) as as shown in Option 1 as-is for SC 4.1.3.

<Zakim> bruce_bailey, you wanted to ask about adding note

Bruce_bailey - Loic raises a good point with regard to providing context and we could do that with a note.

Maryjom - move this to the Friday meeting

<bruce_bailey> regrets for tomorrow

<maryjom> Loïc raised a concern about a note to provide more context - will discuss at a Friday meeting.

Philday added note to google doc

<bruce_bailey> i agree -- i just don't want to loose the thread

Mitch11 - we consensed on the content without a note.

SC 4.1.3: Notes 1 and 2

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-Status-Messages-update/results#xq5

<maryjom> DRAFT RESOLUTION: Incorporate Notes 1 and 2 as proposed in the survey.

<loicmn> +1

+1

<FernandaBonnin> +1

<PhilDay> +1

<PhilDay> NOTE 1: For non-web documents and software where status messages are not implemented using markup languages, there is still a user need to have status messages be programmatically exposed so that they can be presented to the user by assistive technologies without receiving focus. This is typically enabled through the use of accessibility services of the user agent or platform software. NOTE 2: See also the discussion on Closed Functionality.

<olivia> +1

<mitch11> +1

<bruce_bailey> +1

RESOLUTION: Incorporate Notes 1 and 2 for SC 4.1.3 as proposed in the survey.

<Devanshu> +1

<Sam> +1

SC 4.1.3: content for SC problematic for closed functionality

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-Status-Messages-update/results#xq6

+1 option 2

<maryjom> DRAFT RESOLUTION: Incorporate into the proposed SC problematic for closed functionality, the proposed content for SC 3.3.8 as-is.

<PhilDay> Option 2: Proposed change to to the content for 4.1.3: 4.1.3 Status Messages—Requires information in a programmatic determinable form. NOTE Non-web software with closed functionality would need equivalent facilitation to provide access to status messages.

<bruce_bailey> +1

<PhilDay> +1

<loicmn> +1

<Sam> +1

<Devanshu> +1

<olivia> +1

<mitch11> +1

+1

RESOLUTION: Incorporate into the proposed SC problematic for closed functionality, the proposed content for SC 3.3.8 as-is.

Survey results - Question 5 of the Review of proposed responses to public comments - group 1

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-Jan-public-responses/results#xq7

<maryjom> Phil's comments: w3c/wcag2ict#308 (comment)

<PhilDay> Proposed answer that is being discussed: w3c/wcag2ict#308 (comment)

Mitch11: I would have deleted that first paragraph. (Confirming that we are talking about bypass blocks paragraph)

<Zakim> bruce_bailey, you wanted to ask if we have parking lot ?

Bruce_bailey: agree that taking away that paragraph is the better choice. Do we have a parking lot for these things (to find a better home for that paragraph later)

<PhilDay> Proposal from mitch11 is to delete the following paragraph:

<PhilDay> Bypass Blocks is one where (if applied) non-web software would likely automatically satisfy the requirement. Web content has the problem that one cannot quickly navigate to the main part of the content - you have to tab past every menu and navigation link whenever there is a left or top navigation on a website. For a native desktop application, one simply uses a keystroke to toggle between the menu and the main part of the application. For mo[CUT]

<PhilDay> For mobile applications, a user simply taps where they want to start interacting. If navigating sequentially using a screen reader, mobile applications also have much smaller top level menus, meaning the burden of getting past them to get to the main part of the application is minimal - especially when they employ the use of the hamburger menu.

Sam: this is also true for mobile and mobile apps. Such as alt. There are other/different ways in non desktop environments

<bruce_bailey> i kind of wish we had an Understand doc for WCAG2ICT for these sort of examples which will become out of date

Mitch11: my concern is that commenters who are active in WCAG have expressed that there are times that bypass block is needed.

Can we avoid that debate?

Maryjom: Bypass blocks is limited and isn’t being applied to non web software.

Maryjom: it’s not being applied anywhere in the standard. Why are we worrying about this SC if there are no standards that apply it to your softawre?

<Zakim> PhilDay, you wanted to suggest polling the deletion of para 2

<maryjom> Poll: Should we delete the paragraph starting with "Bypass Blocks is one where..."?

<bruce_bailey> +1

<PhilDay> +1

<loicmn> +1

<mitch11> +1

+1

<Devanshu> +1

<olivia> +1

<Sam> +1

<bruce_bailey> +1

<Devanshu> +1

<maryjom> Poll: Remove the “Task Force is unaware…” paragraph?

<Sam> +1

+1

<olivia> +1

<bruce_bailey> +1

<PhilDay> +1

<loicmn> +1

<mitch11> +1, can accept either way

<maryjom> Further comment from issue opener: w3c/wcag2ict#308 (comment)

<PhilDay> https://w3c.github.io/wcag2ict/#software

Mitch11: This last comment, I’m not sure what it is asking. I think he is asking to repeat the note in the definitions.

<PhilDay> https://w3c.github.io/wcag2ict/#set-of-documents

<PhilDay> https://w3c.github.io/wcag2ict/#set-of-software-programs

PhilDay - I thought the same, it was asking for an additional note. I don’t think it’s necessary.

<Zakim> bruce_bailey, you wanted to agree , but want to mention...

<bruce_bailey> > That SC is currently not even being applied by 508 or the EN 301 549 to native applications.

Bruce_Bailey - I don’t agree with removing it.

Maryjom: we are not changing the document. The commenter should look to the standards.

<bruce_bailey> USAB dropped "sets of non-web document" for 508 just because "set of non-web software" was so confusing to people.

PhilDay - native application should be considered as software.

That should be our response.

<bruce_bailey> The 508 preamble discusses the issue.

<PhilDay> https://w3c.github.io/wcag2ict/#software

PhilDay - maybe we can add the link

<maryjom> DRAFT RESOLUTION: Finalize the proposed answer to Issue 308 with the changes proposed by Mitch (removing the two paragraphs polled above) and adding a link in the first sentence to the key term "software".

<loicmn> +1

<mitch11> +1

<PhilDay> +1

<bruce_bailey> +1

<olivia> +1

+1

RESOLUTION: Finalize the proposed answer to Issue 308 with the changes proposed by Mitch (removing the two paragraphs polled above) and adding a link in the first sentence to the key term "software".

<Sam> +1

<PhilDay> +1 to Mitch's sentiment - careful writing is appreciated

<bruce_bailey> +1 to mitch

Survey results - Review of proposed responses to public comments survey results

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-public-comment-group2/results

Issue 77 - Making content usable

<PhilDay> w3c/wcag2ict#77

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-public-comment-group2/results#xq1

<PhilDay> Proposed changes in https://github.com/w3c/wcag2ict/pull/309/files

<maryjom> DRAFT RESOLUTION: Accept the changes and issue answer for Issue 77 as proposed in the survey.

<bruce_bailey> +1

<PhilDay> +1

<mitch11> +1

<loicmn> +1

+1

<Devanshu> +1

<olivia> +1

<Sam> +1

RESOLUTION: Accept the changes and issue answer for Issue 77 as proposed in the survey.

<PhilDay> Proposed addition from survey: Further adjustments have been made to the language and location of documents that are referred to by WCAG2ICT, including "Making Content Usable..." that will hopefully address your concerns in the additional comments (above) in this issue. Note that the WCAG2ICT Task Force needs to remain mindful that this document is not meant to provide techniques for meeting or going beyond WCAG.

<PhilDay> Its content is limited to interpreting WCAG criteria in a non-web context. Any guidance beyond that should instead be included in or referenced by other documents specifically focused on implementing accessibility requirements in non-web technologies. We will continue to mention this resource, but in the context we feel is appropriate for our scope of work.

Issue 145 - Add info/content on the WCAG exemptions in regulatory work

<PhilDay> w3c/wcag2ict#145

<maryjom> https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-public-comment-group2/results#xq2

<Zakim> bruce_bailey, you wanted to suggest we just make fact-based statements

<Chuck> I must depart.

<bruce_bailey> yes, just make fact based-statements