– DRAFT –
WCAG2ICT Task Force Teleconference

Announcements

maryjom: Still 2 SCs for WCAG2.2 that need an author - dragging movements and ...

<GreggVan> can you put the links for those in IRC?

<maryjom> https://github.com/w3c/wcag2ict/wiki/Work-for-the-week#preparation-for-the-19-october-meeting

maryjom: focus not obscured

maryjom: Link above is for the prep for next week

w3c/wcag2ict#39

(dragging movements)

<maryjom> w3c/wcag2ict#39

<maryjom> w3c/wcag2ict#38

issue 38 is focus not obscured

<Sam> I will take up SC 2.4.11

<maryjom> Above 2 links are for SC 2.5.7 and 2.4.11

maryjom: Another reminder

get your surveys done early if at all possible

<bruce_bailey> i appreciated extra reminder for survey !

FPWD public comments

You can always view the wiki to see what work is needed for the coming week - even if the email doesn't go out.

https://github.com/w3c/wcag2ict/wiki/Work-for-the-week

Public comments. There are a number of comments -consider taking some on and drafting a response
… Some of them might need a discussion before completing the response - let Mary Jo know if you think discussion is needed. Otherwise use label function to say Ready for Review.
… For those who have taken on an issue, is there any discussion needed?

bruce_bailey: Since so many are from Melanie, should we schedule a call with her?

maryjom: I think it is more about getting a good answer from the group for her questions, rather than needing to understand her questions.

One example - was heading - we are not putting the short name of the SC in the title. If we do that, then titles get even longer, so we will discuss this later.

<maryjom> w3c/wcag2ict#225

Another example was CSS pixels, which Mitch is working on

GreggVan: Extremely rare is more helpful than 'never known'.
… Just in case you can usually find at least 1 example.

GreggVan: Sets of software - we did find 3 examples last time we looked, but they are rare. Gregg would have to look at notes to find them.

maryjom: Another one that will require discussion. Intent sections; she felt that the document gets too long.
… She suggested a link might suffice
… Maybe keep them in the drafts, but could consider swapping for a link for the final version
… Above are examples of issues that need taking up, and might need discussion

GreggVan: Do we have collapsing text capability? That's a way of having something short, then read the text inline. Not sure if we can do it for notes.
… Chuck to ask if we can collapse elements within Notes

Draft response to Issue 228 on 2.1 Accessibility Services of Platform Software

<maryjom> w3c/wcag2ict#228 (comment)

GreggVan: Mary Jo shares screen to show response number #228
… We can't add in details about what tools could be used - out of scope for us, even if it might be useful.
… Had 5 +1s. Inviting comments from the call...

<Sam> +1 for MJ responce for issue 228

GreggVan: No further comments so issue #228 can move from Draft to released.

<maryjom> Draft RESOLUTION: Send response for issue 228 as-is.

<Sam> +1

<Devanshu> +1

+1

<ShawnT> +1

<Mike_Pluke> +1

<Bryan_Trogdon> +1

RESOLUTION: Send response for issue 228 as-is.

Anyone else that has self assigned an issue - draft then use the Labels function to select [Ready for TF review]

Proposed change to guidance heading text

<maryjom> w3c/wcag2ict#238

maryjom: This is also somewhat in response to one of Melanie's comments

<bruce_bailey> Woot!

maryjom: shows some of the latest changes to draft. Success criteria now have the correct numbering on them which required Daniel to do some post processing.

Thanks to Daniel for the hard work.

PhilDay: Will we break the numbers in the future with other edits?

maryjom: No - we just pull the filename in markdown

<Zakim> bruce_bailey, you wanted to ask about link

maryjom: so it will stay aligned.

bruce_bailey: Requesting link from editors draft. If you go to the Code view of the repository - link is always at the end of the readme at the foot of the page

https://w3c.github.io/wcag2ict/

Reverting to issue #238 on shortening headings, adding SC short name to headings

w3c/wcag2ict#238

This gets rather long and repetitive. MJ worked up some different versions and illustrated how it would look for different types of heading.

Feedback so far on issue; Phil & Olivia like the idea of removing principle, guideline etc from title. Mike not convinced

Sam: Like the shorter one - better for text to speech so you can make it quicker to navigate

Mike_Pluke: I take that point. However, recently went to a group that uses EN 301 549 for evaluating websites. They are not experts, and may not be familiar with WCAG, so adding in extra items might help them to understand.
… Don't feel really strongly.

dmontalvo: Maybe we can go beyond this

Don't even bother with "Applying 1 to" and just do "1 to "

<dmontalvo> Perceivable for Non-Web documents and Software

<dmontalvo> or Principle 1 Perceivable for Non-Web Documents and Software

FernandaBonnin: I agree that titles are long, but agree with comment in the issue. Having them look similar to WCAG guidelines helps to familiarise and understand what you are reading about.
… Think the longer titles is more comprehensible
… Mary Jo shows what is in the document.

Guidance When Applying Guideline 1.4 to.... (we don't have the short name for 1.4)
… All of them have "Guidance when applying 0.0"

If we feel that we must include success criterion, at least put the text after the number to help screen reader users to navigate more quickly

Mike_Pluke: Agree that "Applying Guideline" is less relevant. Also personally substitute SC for success criteria to reduce the text. So could do "Applying SC 1.x SHORT NAME"

GreggVan: Agree with Mike. just define SC at the top, then don't need to type out Success Criteria repeatedly
… Guideline is less of an issue as it is used less commonly.

<maryjom> Applying Principle 1 Perceivable to Non-web Documents and Software

<maryjom> Applying Guideline 1.1 Text Alternatives to Non-web Documents and Software

bruce_bailey: Thinks that for principle and guideline this approach works

<maryjom> Draft RESOLUTION: Change Guideline and principle headings as posted above.

<Mike_Pluke> +1

PhilDay: Suggests adding brackets around the short name, to make it easier to parse the overall title

maryjom: Now showing WCAG 2.2 to show guidelines short names to see if we need additional punctuation.

bruce_bailey: short names are probably OK

<dmontalvo> And also in WCAG itself there's no quotes or punctuation: Guideline 1.1 Text Alternatives

<maryjom> Draft RESOLUTION: Change Guideline and principle headings as posted above.

+1

<Mike_Pluke> +1

<Bryan_Trogdon> +1

<Sam> +1

<FernandaBonnin> +1

<maryjom> +1

<GreggVan> +1

<bruce_bailey> +1

RESOLUTION: Change Guideline and principle headings as posted above.

<maryjom> Option 1: Applying SC 1.1.1 Non-text Contrast to Non-web Documents and Software

For Success criteria, we could just use SC

<maryjom> Option 2: Applying Success Criterion 1.1.1 Non-text Contrast to Non-web Documents and Software

bruce_bailey: With the Success criteria, you have the long part of the success criteria right before this, so we could just use the number in context

<Zakim> PhilDay, you wanted to say use the short name for consistency

PhilDay: Keep short names in the title for consistency

GreggVan: Sometimes people get lost when jumping titles
… so it might be worth using the short name as well, because the numbers are less perceivable

<GreggVan> +1

bruce_bailey: Screen reader users would like to skip, so just put "Applying" at the start to make them easily distinguishable

<maryjom> Poll: Which option is your preference?

1

<FernandaBonnin> 1

<Bryan_Trogdon> 1

<Mike_Pluke> 1

<GreggVan> 1

<Sam> Option 1

<ShawnT> 1

<bruce_bailey> use "sc" i forget if that is 1 or 2

RESOLUTION: Update the headings for the SC guidance using option 1 above.

Only thing left - definitions. Presume we do the same "Applying DEFINITION NAME to non-web..."

<maryjom> DRAFT RESOLUTION: update term definitions to be consistent such as "Applying “accessibility supported” to Non-Web Documents and Software"

+1

<Sam> +1

<GreggVan> +1

<Mike_Pluke> +1

<FernandaBonnin> +1

<Bryan_Trogdon> +1

RESOLUTION: update term definitions to be consistent such as "Applying “accessibility supported” to Non-Web Documents and Software"

Survey results: Closed functionality: SCs 2.1.1, 2.4.2, and 2.4.5

SC 1.2.1.1 Keyboard. 5 responses, split between option 2 or 3

Changes are editorial: "product with closed functionality". Everyone was amenable to both options. Slight majority for option 3, with "products with closed functionality"

No comments heard, so polling.

<maryjom> Option 3: 2.1.1 Keyboard — Requires operation via a keyboard interface which allows alternative input devices. When a closed functionality product either does not have a standard keyboard or one cannot be connected, it would need an alternate way to access all functionality that does not require accurate pointing, path-based movements, or specific timings.

<maryjom> Option 3 with edit: 2.1.1 Keyboard — Requires operation via a keyboard interface which allows alternative input devices. When a product with closed functionality either does not have a standard keyboard or one cannot be connected, it would need an alternate way to access all functionality that does not require accurate pointing, path-based movements, or specific timings.

GreggVan: Keyboard interface is better than just keyboard

<GreggVan> 3

<maryjom> Poll: Incorporate 2.1.1 Keyboard option 3 with edits, as above. 1) Yes 2) no

1

<Sam> 1

<bruce_bailey> 1

<Mike_Pluke> 1

<Bryan_Trogdon> 1

RESOLUTION: Incorporate 2.1.1 Keyboard option 3 with edits, as above. 1) Yes 2) no

RESOLUTION: Incorporate 2.1.1 Keyboard option 3 with edits, as above.

<ShawnT> +1

GreggVan: You can do alternative forms of input (e.g. speech input). How you apply this to closed products. If you close the ability to add other assistive technology, then it becomes more difficult.

2.4.2 Page titled

<bruce_bailey> good edit from Olivia

Next one 2.4.2 Page titled. All liked option 2, Olivia had a slight editorial

Comment was whether we need a definition.

GreggVan: Was going to say the same thing - we need to define it.

<Sam> +1

<maryjom> DRAFT RESOLUTION: Accept Option 2 for 2.4.2 Page Titled, as-is.

<Sam> +1

<GreggVan> +1

+1

<Devanshu> +1

<Bryan_Trogdon> +1

<Mike_Pluke> +1

RESOLUTION: Accept Option 2 for 2.4.2 Page Titled, as-is.

<bruce_bailey> +1

<GreggVan> +++

RESOLUTION: Accept Option 2 for 2.4.2 Page Titled, as-is.

Survey contains definition for menu driven interface