– DRAFT –
WCAG2ICT Task Force Teleconference

regrets/

Link for agenda: https://github.com/w3c/wcag2ict/wiki/Agendas

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

Announcements

W3C: current CEO has resigned, so there is a transition period to find a new CEO. For now Dominque is the interim CEO

Nothing to indicate a change in direction.

https://urldefense.com/v3/__https://www.w3.org/press-releases/__;!!D5WlZnHMtQ!UWJcwKwqTxoWQUn3_q8B_oXL-w6obW-SDuYuph2sv64A2FL5IGhlITgVqm4YCOP_OLUdJr5Lj_z7trPo$

<Daniel> Press Release

<Daniel> https://www.w3.org/press-releases/2026/w3c-leadership-transition/

3.1.4 Abbreviations - Proposed content to review

<LauraM> w3c/wcag2ict#559

Proposed content (from issue).

Applying SC 3.1.4 Abbreviations to non-web documents

This success criterion is problematic to apply directly to non-web documents because not all document formats provide support for a mechanism to provide the expanded form or meaning of abbreviations. Where the non-web document format provides such a mechanism, the non-web document should work with these features to the extent the format provides.

Doing so would still address the user needs identified in Intent from Understanding Success Criterion 3.1.4.

Applying Applying SC 3.1.4 Abbreviations to non-web software

This success criterion is problematic to apply directly to non-web software because not all platforms provide support for a mechanism to provide the expanded form or meaning of abbreviations. Non-web software needs to work with platform capabilities where they exist, but when the platform does not provide capabilities, it is unreasonable for all

apps on a particular platform to build in their own mechanism to provide the expanded form or meaning of abbreviations. Where the platform does provide a suitable mechanism, the non-web software should work with these features to the extent the platform provides. Doing so would still address the user needs identified in Intent from Understanding

Success Criterion 3.1.4.

NOTE (FOR NON-WEB SOFTWARE)

See also the Comments on Closed Functionality.

And in SC problematic for closed:

3.1.4 Abbreviations - This success criterion is problematic to apply to ICT with closed functionality as they may not provide support for a mechanism to provide the expanded form or meaning of abbreviations.

GreggVan: Makes sense for documents. Software - if there isn't a mechanism, you should just add it.

<Zakim> PhilDay, you wanted to say it is about the platform

PhilDay: It's about the platform - if it is not in the platform, then it may be unreasonable to expect apps to add this feature

GreggVan: Think you could still expect apps to add some support for abbreviations. You could at least describe the abbreviations

bbailey: Think it applies as written to software

<Zakim> loicmn, you wanted to ask which criterion we are dealing with 3.1.3 or 3.1.4

bbailey: Most of the time you are relying on software to pick up what is an abbreviation

loicmn: Which SC? 3.1.4 or 3.1.3

For 3.1.3 we agreed that it was not reasonable for apps to implement their own mechanism. So it makes sense to use the same approach for 3.1.4 if we have already agreed 3.1.3

<bbailey> https://w3c.github.io/wcag2ict/#unusual-words

GreggVan: Think we should say it applies as written (for software). Then put a note to say help could be a mechanism to explain an abbreviation.
… It doesn't need to be provided inline - just offer some mechanism like help

Daniel: Agree with Gregg's - providing feature another way like a help feature is appropriate.

<loicmn> +1 to Gregg, but we must do the same for 3.1.3

ACTION: Editors to rework both 3.1.4 and 3.1.3 to maintain consistency

<bbailey> I am not loving what we have for 3.1.3...

LauraM clarifying that we should agree content for 3.1.4, and then go back and edit 3.1.3

<Zakim> bbailey, you wanted to ask when we did 3.1.3 ?

Proposed text for 3.1.4:

Applying Applying SC 3.1.4 Abbreviations to non-web software

This success criterion applies as written as described in Intent from Understanding Success Criterion 3.1.4.

NOTE

Help is a mechanism for software that can provide explanations of abbreviations. This would address the user needs identified in Intent from Understanding Success Criterion 3.1.4.

<LauraM> 3.1.4 Abbreviations - This success criterion applies as written for software (with no note about closed functionality)

<LauraM> NOTE: Help is a mechanism for software that can provide explanations of abbreviations

<LauraM> (Use PhilDay version)

<Daniel> +1

<bbailey> +1

<loicmn> +1

<LauraM> +1

<Jim> +1

<PhilDay> +1

<GreggVan> +1

<LauraM> DRAFT RESOLUTION: For 3.1.4 Abbreviations to non-web software Applying Applying SC 3.1.4 Abbreviations to non-web software

<LauraM> This success criterion applies as written as described in Intent from Understanding Success Criterion 3.1.4.

<LauraM> NOTE: Help is a mechanism for software that can provide explanations of abbreviations. This would address the user needs identified in Intent from Understanding Success Criterion 3.1.4.

<LauraM> 3.1.4 Abbreviations - This success criterion applies as written for software (with no note about closed functionality)

<LauraM> NOTE: Help is a mechanism for software that can provide explanations of abbreviations

<bbailey> +1

<loicmn> +1

<PhilDay> +1

<GreggVan> +1

RESOLUTION: For 3.1.4 Abbreviations to non-web software Applying Applying SC 3.1.4 Abbreviations to non-web software

<LauraM> This success criterion applies as written as described in Intent from Understanding Success Criterion 3.1.4.

<LauraM> NOTE: Help is a mechanism for software that can provide explanations of abbreviations. This would address the user needs identified in Intent from Understanding Success Criterion 3.1.4.

<LauraM> 3.1.4 Abbreviations - This success criterion applies as written for software (with no note about closed functionality)

<LauraM> NOTE: Help is a mechanism for software that can provide explanations of abbreviations

<LauraM> DRAFT RESOLUTION: Proposed edits to 3.1.3 to make consistent with above 3.1.4

<loicmn> +1

<PhilDay> +1

<GreggVan> +1

<bbailey> +1

<LauraM> +1

<Daniel> +1

<Jim> +1

RESOLUTION: Proposed edits to 3.1.3 to make consistent with above 3.1.4

3.1.5 Reading Level - Proposed content to review

<LauraM> w3c/wcag2ict#560

Proposed content for review by TF:

3.1.5 Reading Level

(Level AAA)

When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available.

Applying SC 3.1.5 Reading Level to non-web documents

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.5.

Applying SC 3.1.5 Reading Level to non-web software

This success criterion may be problematic to apply directly to non-web software because not all platforms provide support for providing supplemental content, or alternative versions of content (such as a version that does not require reading ability more advanced than the lower secondary education level). Non-web software needs to work with

platform capabilities where they exist, but when the platform does not provide capabilities, it is unreasonable for all apps on a particular platform to build in their own mechanism to provide supplemental content or alternative versions. Where the platform does provide a suitable mechanism, the non-web software should work with these features to

the extent the platform provides. Doing so would still address the user needs identified in Intent from Understanding Success Criterion 3.1.5.

NOTE (ADDED) (NON-WEB SOFTWARE)

See also the Comments on Closed Functionality.

And in SC problematic for closed:

3.1.5 Reading Level - This may be problematic to apply for ICT with closed functionality, as there may be no method of providing supplemental content or alternative versions. Ensuring that the text provided by the ICT with closed functionality is no more advanced than the lower secondary education level would still address the user needs identified

in Intent from Understanding Success Criterion 3.1.5.

<Daniel> w3c/wcag2ict#560

<LauraM> GreggVan: Change sentence to remove redundancy: Where the platform does provide a suitable mechanism, the non-web software should work with these features.

bbailey: Suggest we take a similar approach to 3.1.4 - applies as written for software, add a note

Proposal to address bbailey's suggestion (by moving note to software, rather than just for closed). But still saying it is problematic.

Applying SC 3.1.5 Reading Level to non-web documents

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.5.

Applying SC 3.1.5 Reading Level to non-web software

This success criterion may be problematic to apply directly to non-web software because not all platforms provide support for providing supplemental content, or alternative versions of content (such as a version that does not require reading ability more advanced than the lower secondary education level). Non-web software needs to work with

platform capabilities where they exist, but when the platform does not provide capabilities, it is unreasonable for all apps on a particular platform to build in their own mechanism to provide supplemental content or alternative versions. Where the platform does provide a suitable mechanism, the non-web software should work with these features.

NOTE

Ensuring that the text provided by the ICT with closed functionality is no more advanced than the lower secondary education level would still address the user needs identified in Intent from Understanding Success Criterion 3.1.5.

GreggVan: Not sure it can apply as written for software in all cases

bbailey: Think it is the same problem for web software - not sure why we should add a caveat for non-web software
… OK if a Physics application uses advanced terminology.

NOTE

Ensuring that the text provided by the ICT with closed functionality is no more advanced than the lower secondary education level would still address the user needs identified in Intent from Understanding Success Criterion 3.1.5.

<Zakim> PhilDay, you wanted to suggest applies as written with single note

<bbailey> i am all for keeping a note

NOTE

Ensuring that the text provided by the non-web software is no more advanced than the lower secondary education level would still address the user needs identified in Intent from Understanding Success Criterion 3.1.5.

NOTE

Help can be a mechanism for explaining

<LauraM> PhilDay: Second note needs padding out

GreggVan: Why don't we state it as an exception - and reference trigonometry as an example of a concept that is above the reading level

GreggVan: NOTE 1 should be phrased as an exception

NOTE 2 is OK.

<Zakim> loicmn, you wanted to say that NOTE 1 is already in the SC and NOTE 2 can be rephrased to refer to supplemental content

loicmn: NOTE 1 is already implied in the SC, so can be removed.

The other note could be modified to explicitly refer to supplemental content

NOTE

Help can be a mechanism for providing supplemental content.

<Daniel> SC says: When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available.

loicmn: This is a problem in WCAG - and that is why it is AAA

<loicmn> NOTE Help can be a mechanism for providing supplemental content

<Zakim> bbailey, you wanted to agree with not fixing WCAG 2.2

bbailey: Agree that we are not fixing WCAG 2.2, but we should capture and pass back to WCAG 2.2.

<Zakim> PhilDay, you wanted to clarify what we now have

GreggVan: But it's AAA so we don't need to apply

<LauraM> PhilDay: Clarification - We are saying that the software applies directly as written and not sure about the rest

loicmn: Remove exception, keep note about help

Daniel: The SC doesn't contain any exception.

GreggVan: When it applies - is a form of exception

<PhilDay> +1 to loicmn: delete exception, add a note

Latest proposed content for software:

Applying SC 3.1.5 Reading Level to non-web software

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.5,

NOTE

Help can be a mechanism for providing supplemental content.

<PhilDay> +1 to remove exception, just add 1 note

LauraM: +1 if you agree with this approach

<bbailey> +1

Proposed content

Applying SC 3.1.5 Reading Level to non-web documents

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.5.

Applying SC 3.1.5 Reading Level to non-web software

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.5,

NOTE

Help can be a mechanism for providing supplemental content.

Applying SC 3.1.5 Reading Level to non-web documents and non-web software

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.5.

NOTE

Help can be a mechanism for providing supplemental content.

<bbailey> +1

Applying SC 3.1.5 Reading Level to non-web documents and non-web software

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.5.

NOTE (SOFTWARE)

Help can be a mechanism for providing supplemental content.

<GreggVan> DRAFT RESOLUTION: Appliesa as written to NWS and NWD along with a note on software that reads " Help can be a mechanism for providing supplemental content."

<LauraM> DRAFT RESOLUTION: Proposed content Applying SC 3.1.5 Reading Level to non-web documents and non-web software This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.5.

<LauraM> NOTE

<LauraM> Help can be a mechanism for providing supplemental content.

<LauraM> DRAFT RESOLUTION: Proposed content Applying SC 3.1.5 Reading Level to non-web software This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.5. NOTE Help can be a mechanism for providing supplemental content.

<PhilDay> +1

<Jim> +1

<loicmn> +1

<LauraM> +1

<bbailey> +1

<GreggVan> DRAFT RESOLUTION: Proposed content Applying SC 3.1.5 Reading Level to non-web documents and non-web software This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.5. with a note on software NOTE Help can be a mechanism for providing supplemental content.

<PhilDay> +1

<GreggVan> s /not on/ note on/

<bbailey> +1

<loicmn> +1

<Daniel> +1

<Jim> +1

<GreggVan> +1

RESOLUTION: Proposed content Applying SC 3.1.5 Reading Level to non-web documents and non-web software This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.5. with a note on software NOTE Help can be a mechanism for providing supplemental content.

3.1.6 Pronunciation - Discussion, Laura

<bbailey> w3c/wcag2ict#937

3.3.5 Help - Discussion, Bruce

w3c/wcag2ict#563

See: https://deploy-preview-937--wcag2ict.netlify.app/#help

Proposal:

Applying SC 3.3.5 Help to non-web documents and non-web software

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.5.

NOTE 1 (ADDED)

As noted in [glossary item context-sensitive help], clear labels or other information provided by the system can act as context-sensitive help.

NOTE 2 (ADDED) (FOR NON-WEB SOFTWARE)

See also the Comments on Closed Functionality.

bbailey: Applies directly as written, 2 notes added

LauraM: Any disagreement with this approach?

bbailey: Did have 1 question
… Do we want to say something about non-web documents - to differentiate between media players and static docs

Proposed NOTE (FOR NON-WEB DOCUMENTS)

This success criterion readily applies to player/viewer software application. This success criterion is generally not applicable to static non-web documents. It is possible for some non-web file formats to include interactive elements that are specific to the document and independent of the software used. Examples of non-web documents that can

directly support context-sensitive include, but are not limited to, PDF forms, complex spreadsheets, and database source files.

Latest update from Bruce: Applying SC 3.3.5 Help to non-web documents and non-web software

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.5.

NOTE 1 (ADDED)

As noted in [glossary item context-sensitive help], clear labels or other information provided by the system can act as context-sensitive help.

NOTE 2 (ADDED) (FOR NON-WEB SOFTWARE)

See also the Comments on Closed Functionality.

NOTE (NON-WEB DOCUMENTS)

This success criterion readily applies to player/viewer software application. This success criterion is generally not applicable to static non-web documents. It is possible for some non-web file formats to include interactive elements that are specific to the document and independent of the software used. Examples of non-web documents that can

directly support context-sensitive include, but are not limited to, PDF forms, complex spreadsheets, and database source files.

NOTE (NON-WEB DOCUMENTS)

This success criterion readily applies to player/viewer software application. This success criterion is problematic to apply to static non-web documents. It is possible for some non-web file formats to include interactive elements that are specific to the document and independent of the software used. Examples of non-web documents that can directly

support context-sensitive include, but are not limited to, PDF forms, complex spreadsheets, and database source files.

<LauraM> DRAFT RESOLUTION: Proposal:

<LauraM> Applying SC 3.3.5 Help to non-web documents and non-web software

<LauraM> This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.5.

<LauraM> NOTE 1 (ADDED)

<LauraM> As noted in [glossary item context-sensitive help], clear labels or other information provided by the system can act as context-sensitive help.

<LauraM> NOTE 2 (ADDED) (FOR NON-WEB SOFTWARE)

<LauraM> See also the Comments on Closed Functionality NOTE 3 (FOR NON-WEB DOCUMENTS)

<LauraM> This success criterion readily applies to player/viewer software application. This success criterion is problematic to apply to static non-web documents. It is possible for some non-web file formats to include interactive elements that are specific to the document and independent of the software used. Examples of non-web documents that can directly

<LauraM> support context-sensitive include, but are not limited to, PDF forms, complex spreadsheets, and database source files

<PhilDay> +1

<LauraM> DRAFT RESOLUTION 3.3.5 Help add three notes as written above

<PhilDay> +1

<loicmn> +1

<bbailey> +1

<Daniel> +1

<Jim> +1

<GreggVan> +1

<LauraM> +1

<LauraM> RESOLUTION 3.3.5 Help add three notes as written above

ACTION: bbailey to fix PR

bbailey will fix PR which was in draft, and then make final