Meeting minutes
Announcements
<Zakim> bbailey, you wanted to ask about ::: markdown
bbailey: WCAG3 repo - instead of using HTML on divs, they are using :::style:::
Daniel: Unfortunately this project was created before these changes - but good to use in the future
… We would have to change the existing document and scripting - probably not worth it as we are nearly finished
… Daniel also considering using some of this in ReSpec.
Daniel: Suggest we stick with what we have for this project
Note 3 SC 4.1.1
ISSUE: w3c/
SC 4.1.1 deprecated. Discussion about whether we need an extra note or not. Mitch was asked for input. He supports not adding NOTE 3
Original proposal from Gregg: NOTE 3 (ADDED)
Although 4.1.1 is deprecated in WCAG 2.2, this was done because the accessibility issue is currently taken care of in modern browsers where they create a repaired DOM, so this provision was no longer needed for web content. However, unless the non-web document or the markup content in the software will only be rendered by the same type of engine as
is used in modern browsers (and repairs syntax errors), this provision should not be deprecated for non-web documents and non-web software.
Rewording by Bruce: Success criterion 4.1.1 is deprecated in WCAG 2.2 because the accessibility issues is addressed in modern browsers because they create a repaired document object model (DOM) and this provision is no longer needed for web content. However, unless the non-web document or the markup content in the software will only be rendered by
the same type of engine as is used in modern browsers (and repairs syntax errors), this provision should not be deprecated for non-web documents and non-web software.
<Laura> DRAFT RESOLUTION: For 4.1.1 - no note 3 needed
<PhilDay> +1
<bbailey> +1
<loicmn> +1
<Daniel> +1
<JamesH> +1
<mitch11> +1
RESOLUTION: For 4.1.1 - No note 3 needed
Daniel: Gregg was the original proponent, but also said he could accept not adding the note
<Daniel> w3c/
GreggVan: OK either way - has it been established that all HTML used in applications are processed using web browser interpretation engines?
<GreggVan> +1
mitch11: There is no evidence that markup is consumed directly by any AT.
GreggVan: Then there is no need for the note
Consistency with WCAG2ICT style in "Where ICT..."
ISSUE: w3c/
<Laura> Proposal 1: keep the positive phrasing
<Laura> Applying SC 1.2.9 Audio-Only (Live) to non-web documents and non-web software
<Laura> This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.9 where the non-web software or non-web document technology supports incorporation of live audio-only content.
<Laura> Proposal 2: convert to negative phrasing for consistency with other similar SCs (1.3.4, 2.4.5, 2.5.8 )
<Laura> This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.9, except for non-web software or non-web documents that do not support incorporation of live audio-only content.
PhilDay: prefers proposal 2 but happy with either.
<Zakim> Daniel, you wanted to say I also prefer 2
<bbailey> +1 to proposal 2
Daniel: prefers option 2
PhilDay: Also prefer option 2
<GreggVan> option 1
Poll: Proposal 1 keep phrasing and Proposal 2 convert to negative phrasing, write 1 or 2
<bbailey> I would call it "exception phrasing" rather than "exception phrasing"
GreggVan: Prefer option 1 with reversed order (i.e. as it was originally)
… More consistent with the order that is used in EN 301 549
… Put condition first, then if you don't meet the condition, you don't read the rest
<bbailey> i like it, but that's a big editorial change late in our process
To confirm, GreggVan, reorder so that it says "Where the non-web document or non-web software technology supports incorporation of live audio-only content, this applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.9"?
GreggVan: Still think it is a good idea, but maybe we go with proposal 2 at this late stage as it is the same form as the rest of the document
Then in WCAG3 we flip the order
GreggVan: Think proposal 2 is clearer - so changed my mind for this document, support proposal 2
GreggVan: EN 301 549 is finalized. Going out for a vote, no changes can be made - it cannot be changed - just accept/rejected. Gregg is getting a diff together to compare old to new
GreggVan: It passed last time - so it should pass this time as we've done the minor edits that were requested
PhilDay: Agree with Gregg, the order he suggetss wouldd be logical if starting from scratch, but we need to stick to our environment
mitch11: Don't have strong preference on proposals, but would suggest we remove the exception from this criterion as it is already implied in the SC.
Proposal 3: remove exception
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.9.
Daniel: Agree with mitch11 that we don't need the exception, but think there was an appetite to make it explicit here.
Poll: Proposal 1 keep phrasing and Proposal 2 convert to negative phrasing, Proposal 3 remove exception - Write 1, 2, 3
bbailey: In the beginning we were adding exceptions all over the place - then later changed our approach slightly. So would support removing the exception
<GreggVan> 3
<loicmn> 3
<mitch11> 3
<bbailey> 3
<Daniel> 3
2 then 3 - would be happy with either
Draft Resolution: Proposal 3
Draft Resolution: Remove Exception (proposal 3)
<loicmn> +1
<mitch11> +1
<bbailey> Proposal 3 was at 25 past hour
<JamesH> +1
<Daniel> +1
<bbailey> +1
<PhilDay> +1
RESOLUTION: Remove Exception (proposal 3)
<GreggVan> +1
SC 2.1.1 'Problematic for Closed' suggests ways of meeting SC 2.1.1 Keyboard that don't align with the SC.
ISSUE: w3c/
Mitch opened this issue last week
mitch11: In summary: Under problematic for closed, comment on SC 2.1.1 Keyboard suggests that providing a keyboard would be a way to meet 2.1.1.
… However WCAG itself refers to keyboard interfaces - not just keyboards
… Suggest we just leave it as problematic, rather than imply that adding a keyboard meets
Laura (with chair hat off): Would be good to remove any reference to hardware like keyboard
<bbailey> +1 to laura and avoiding mention of hardware to the extent possible
GreggVan: In all cases it is the keyboard interface that is the important factor - not the physical keyboard anyway - it's the interface that is the important bit. We should talk about keyboard interfaces.
Proposal 1: 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices. In a closed environment where a keyboard interface is not available, it may not be possible to meet this criterion, and some other non-WCAG requirements would be needed to ensure that content is operable by persons with limited
mobility and persons without vision.
Proposal 2: 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices.
GreggVan: On a product that is closed, you do not allow AT, therefore you have to include all functionality that would be in the AT
GreggVan: Should handle the same as other similar SCs
mitch11: proposal is not to change the guidance for the SC (for open systems). It is only in the problematic for closed section.
… To make it more similar to 1.1.1 and 1.3.1
GreggVan: Suggests 3rd proposal
Proposal 3
2.1.1 Keyboard — Assumes access to the keyboard interface by AT which also allows for alternate input devices.
Proposal 3
2.1.1 Keyboard — Assumes access to the keyboard interface by AT which then allows for alternate input devices.
Poll: Vote 1 or 2 or 3 - Proposal 1 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices. In a closed environment where a keyboard interface is not available, it may not be possible to meet this criterion, and some other non-WCAG requirements would be needed to ensure that content is operable
by persons with limited mobility and persons without vision.
Proposal 2 - 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices.
Proposal 3 - 2.1.1. Keyboard - Assumes access to a keyboard interface via AT which then allows for alternate input devices
<Zakim> PhilDay, you wanted to say we do add additional help sometimes
PhilDay: Support proposal 1 as additional guidance is helpful
mitch11: Tweak proposal 3
Proposal 3
2.1.1 Keyboard — Assumes access to a keyboard interface by AT which then allows for alternate input devices.
Poll: Vote 1 or 2 or 3 - Proposal 1 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices. In a closed environment where a keyboard interface is not available, it may not be possible to meet this criterion, and some other non-WCAG requirements would be needed to ensure that content is operable
by persons with limited mobility and persons without vision.
Proposal 2 - 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices.
Proposal 3 - 2.1.1 Keyboard — Assumes access to the keyboard interface by AT which then allows for alternate input devices.
GreggVan: Proposal 1 is wrong - will be happy to explain why
Poll: Vote 1 or 2 or 3 - Proposal 1 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices. In a closed environment where a keyboard interface is not available, it may not be possible to meet this criterion, and some other non-WCAG requirements would be needed to ensure that content is operable
by persons with limited mobility and persons without vision.
Proposal 2 - 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices.
Proposal 3 - 2.1.1 Keyboard — Assumes access to a keyboard interface by AT which then allows for alternate input devices.
<loicmn> me made a mistake in q... I support proposal 1
GreggVan: Keyboard interface is available - it is just not accessible by the AT.
<Zakim> bbailey, you wanted to ask about place ment of this note?
bbailey: Asked for clarification on where it should be placed. Proposal 2 could be put in general note in SC. Proposal 1 needs to be tweaked as per Gregg's comments.
<Zakim> loicmn, you wanted to support proposal 3 as we should not mention AT in the section on closed
loicmn: Issue I have with proposal 3 - you should not reference AT as users cannot connect AT. So this proposal doesn't make sense.
loicmn: Think we should use something aligned with proposal 1, even if we rewrite it.
Proposal 1 - Phil possible reword
2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices. In a closed environment where external access to a keyboard interface is not allowed, it may not be possible to meet this criterion, and some other non-WCAG requirements would be needed to ensure that content is operable by persons with
limited mobility and persons without vision.
<bbailey> i like keeping the commentary (after re-write) but i don't think we should try and wordsmith on today's call
GreggVan: Why we don't add a 2nd sentence to proposal 3.
loicmn: We would have to explain that AT is not usually allowed to be connected to closed
<GreggVan> Proposal 3 - 2.1.1 Keyboard — Assumes access to a keyboard interface by AT which then allows for alternate input devices but is not true for closed functionality. Therefore some other non-WCAG requirements would be needed to ensure that content is operable
<mitch11> In case it helps for 2.1.1, here's what we currently say at the top of the "Problematic" section (emphasis mine):
<mitch11> Some criteria discuss making information available in text (which can be read by assistive technologies), making it “programmatically determinable” (rendered by a user agent and readable by assistive technologies), *or doing something else to make content compatible with assistive technologies.* Where ICT with closed functionality *doesn’t
<mitch11> support use of assistive technology* or the platform does not have an accessibility API, 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 these success criteria.
<GreggVan> Proposal 3 - 2.1.1 Keyboard — Assumes access to a keyboard interface by AT is not true for closed functionality. This access would have allowed for alternate input devices. Therefore some other non-WCAG requirements would be needed to ensure that content is operable
<bbailey> +1
GreggVan: Last part of it is truncated
<GreggVan> by persons with some disabilities.
<GreggVan> Proposal 3 - 2.1.1 Keyboard — Assumes access to a keyboard interface by AT is not true for closed functionality. This access would have allowed for alternate input devices. Therefore some other non-WCAG requirements would be needed to ensure that content is operable by persons with some disabilities.
Proposal 4 - Phil possible reword of proposal 1
2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices. In a closed environment where external access to a keyboard interface is not allowed, it may not be possible to meet this criterion, and some other non-WCAG requirements would be needed to ensure that content is operable by persons with some
disabilities including limited mobility and persons without vision.
Proposal 4 - Phil possible reword of proposal 1
2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices to be connected. In a closed environment where external access to a keyboard interface is not allowed, it may not be possible to meet this criterion, and some other non-WCAG requirements would be needed to ensure that content is operable by
persons with some disabilities including limited mobility and persons without vision.
2.1.1 Keyboard — Assumes access to a keyboard interface by AT is not true for closed functionality. This access would have allowed for alternate input devices. Therefore some other non-WCAG requirements would be needed to ensure that content is operable
GreggVan: prefer to not use the word connect
Proposal 4 (which is Proposal 3 with some of Proposal 1) - 2.1.1 Keyboard — Assumes access to a keyboard interface by AT is not true for closed functionality. This access allows for alternate input devices. Therefore some other non-WCAG requirements would be needed to ensure that content is operable
<bbailey> proposal 4 has a grammar issue, sorry
Poll: Proposal 1 - 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices. In a closed environment where a keyboard interface is not available, it may not be possible to meet this criterion, and some other non-WCAG requirements would be needed to ensure that content is operable by persons with
disabilities.
Proposal 2 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices.
Proposal 3 - 2.1.1 Keyboard — Assumes access to a keyboard interface by AT which then allows for alternate input devices.
Proposal 4 (which is Proposal 3 with some of Proposal 1) - 2.1.1 Keyboard — Assumes access to a keyboard interface by AT is not true for closed functionality. This access allows for alternate input devices. Therefore some other non-WCAG requirements would be needed to ensure that content is operable
Proposal 1, 2, 3, or 4 above.
<mitch11> 4, fixing grammar in its first sentence. Can accept any.
Proposal 5 - Phil possible reword of proposal 1
2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices to be used. In a closed environment where external access to a keyboard interface is not allowed, it may not be possible to meet this criterion, and some other non-WCAG requirements would be needed to ensure that content is operable by
persons with some disabilities including limited mobility and persons without vision.
bbailey: Suggest proposal 4 should have the same first sentence as proposal 1
<bbailey> or Proposal 4 should start with same sentence as proposal 3
Looks like we have finished everyone!
<loicmn> me Yes. Good bye all
Proposal 5 has been added to the issue. If you have time, please review the issue and make comments, and we shall pick this up next week
<GreggVan> yes - call ended for me as well
Thanks to all for your time. We'll pick it up next week.