Meeting minutes
Announcements
Maryjom: not sure if we have regrets.
maryjom: I tried to clarify with the Web Accessibility Initiative folks that we would like to republish the WCAG2ICT note. Tried to find out how heavy a lift that will be.
maryjom: AG working group will have to review. The consensus is that we can do a lightweight process because most is editorial with a few additional notes.
maryjom: They did not seem to be concerned. It should slice off the publication time. CFC call for consensus to republish. Daniel has been out so we will need to catch him out upon return.
<Zakim> bbailey, you wanted to ask if we are not versioning
Bbailey: I don't think we are ready to publish a new version because we have not done the AAA portion.
maryjom: This is just a stepwise version
Maryjom: We will be working on a continuum.
Maryjom: It is important that the EN have a version that shows the language that we agree on.
maryjom: If questions come up they can reference the published version of WCAG2ICT.
maryjom: We can get Daniel onboard and then finish the EN 301549 affecting items.
maryjom: We are not stopping, it's on a continuum.
PR Proposal approvals and discussions of issues affecting the EN 301 549
Issue 705 – 2.5.2 Pointer cancellation
<maryjom> Link to issue 705: w3c/
<maryjom> Link to PR 717: w3c/
<bbailey> I was concerned for a bit because there is *also* https://
Issue 702 - 1.3.1: The EN 301 549 added a note for non-web documents we should consider including in WCAG2ICT
<maryjom> Link to issue 702: w3c/
<maryjom> Link to PR 715: w3c/
<ChrisLoiselle> Mary Jo, could you share your screen?
<maryjom> NOTE: Where non-web documents contain non-standard structure types (roles), it is best practice to map them to a standard structure type as a fall-back solution for the reader.
<maryjom> In-context the PR adding the note: https://
GreggVan: Harmonizing with EN should be our focus because they are further along than we are.
<maryjom> POLL: Should we add Note 1 for non-web documents?
<GreggVan> +1
<bbailey> +1
<loicmn> +1
<Mike_Pluke> +1
<ChrisLoiselle> +1
<LauraM> +1
RESOLUTION: Add the proposed Note 1 for non-web documents to SC 1.3.1, as-is
Issue 702 - 1.3.1: The EN 301 549 added a note for non-web documents we should consider including in WCAG2ICT
<maryjom> Link to issue 702: w3c/
<maryjom> Link to PR 715: w3c/
Issue 691 - Differences between 2.1.1 keyboard guidance in WCAG2ICT and EN 301 549 content in clause 11.2.1.1 Keyboard
<maryjom> Link to issue 691: w3c/
<maryjom> Link to PR 718: w3c/
<maryjom> In WCAG2ICT Note 1 middle sentence is: Platform software may provide a ‘keyboard interface’ that software can read instead of reading any keyboard hardware directly.
<maryjom> In the EN 301 549 it is: Platform software may provide device independent input services to applications that enable operation via a keyboard interface.
<ChrisLoiselle> https://
bbailey: I agree it would be better not to talk about documents when we are talking about web.
bbailey: is this a style question
maryjom: We will wait to discuss the style when Daniel returns.
<ChrisLoiselle> Laura: Is the significant use of platform software term use differs ?
<ChrisLoiselle> Platform software vs. platform service . Are they equivalent ? Is it correct?
greggvan: The service is one thing that the platform provides.
<maryjom> Keyboard interface does not refer to a physical device but to a service of the platform software...
GreggVan: should say "But to the service of the platform software"
ChrisLoiselle: so what you are showing in parenthesis says for non-web software. And then software or non-web document functionality. Do we need to duplicate this note for non web documents?
Mike_Pluke: We do use Platform Services. It is not defined. We talk about Platform accessibility services. Whatever we choose here will need to be tightened up.
bbailey: Note 1 proposal 1 - is that what is in EN 301549?
Maryjom: They changed the middle sentence.
<Zakim> bbailey, you wanted to discuss clarification where EN 301 549 is with this note?
<Zakim> GreggVan, you wanted to say a) we should use platform software, service of platform software and b) put the note under docs and software
<Zakim> bbailey, you wanted to ask if we need to split
<ChrisLoiselle> +1 to Bruce's point as that was my point on non-web documents vs. non-web software references within notes
<maryjom> Keyboard interface does not refer to a physical device but to the service of platform software (e.g. operating system, browser, etc.) that provides the software with keystrokes from any keyboard or keyboard substitute. When the "non-web document/software supports such a device-independent service of the platform software, and the "non-web
<maryjom> document/software" functionality is made fully operable through the service, then this success criterion would be satisfied.
<maryjom> s/"software supports/"software" supports/
<maryjom> Keyboard interface does not refer to a physical device but to the service of platform software (e.g. operating system, browser, etc.) that provides the software with keystrokes from any keyboard or keyboard substitute. When the non-web "document/software" supports such a device-independent service of the platform software, and the non-web
<maryjom> "document/software" functionality is made fully operable through the service, then this success criterion would be satisfied.
<Zakim> bbailey, you wanted to say i think [non-web document and software] can just be [non-web software]
bbailey: We are not talking about non web documents. Should we change the note to reflect that?
<maryjom> Keyboard interface does not refer to a physical device but to the service of platform software (e.g. operating system, browser, etc.) that provides the software with keystrokes from any keyboard or keyboard substitute. When the non-web software supports such a device-independent service of the platform software, and the non-web software
<maryjom> functionality is made fully operable through the service, then this success criterion would be satisfied.
<GreggVan> +1
<loicmn> +1 to that version of the note
<bbailey> +1
<Mike_Pluke> +1
<ChrisLoiselle> +1 makes sense in context of what you are stating
RESOLUTION: Modify Note 1 of 2.1.1 Keyboard to the text noted in IRC above
<GreggVan> +1
<bbailey> +1
<Mike_Pluke> +1
<ChrisLoiselle> ok on editorial and e.g. comma topic
<Zakim> LauraM, you wanted to say can character input replace keystrokes?
<ChrisLoiselle> LauraM: keystrokes term is still in question for me and input mechanisms.
greggvan: There are many things that can be used as input. We we're saying that things have to use the keyboard interface.