– DRAFT –
WCAG2ICT Task Force Teleconference

Announcements

Did start AG WG review of our draft note. They asked for a 2 week review period due to the US holidays

It will continue until December 2nd 2025

Keep an eye out for comments on the issue.

w3c/wcag2ict#812

There are comments from Andrew Kirkpatrick currently

<maryjom> Link to issue 527: w3c/wcag2ict#527

We answered issue 527 a couple of weeks ago

There continues to be debate on this issue

We shall pick this up in 2 weeks time (no call next week)

Remember. There is no meeting next Thursday. There will be 2 meetings in the first 2 weeks of December, then nothing until January.

First meeting in January will be Thursday 8th January 2026

Has anyone seen the updated version of EN 301 549?

There were some changes after v20. Loic can get access to it.

AG WG WCAG2ICT review comments

First review comment received from Andrew K - on AG WG

<maryjom> Link to Issue 812: w3c/wcag2ict#812

<maryjom> Link to Andrew’s comments: w3c/wcag2ict#812 (comment)

Comments on audio description SCs (1.2.3, 1.2.5). Suggested a slight edit

1.2.3/1.2.5: The current version introduces a new concept "audio-video media" which is undefined. Instead of:

When audio descriptions are needed, one way to implement them is by providing a second audio track for the audio-video media.

How about: "When audio descriptions are needed, one way to implement them is by providing a second audio track within the synchronized media." (which is what the SC indicates is the focus of the criteria).

(first of Andrew's comments)

[maryjom sharing screen, showing issue 812]

<bbailey> I like all three of AWK edits.

This first comment makes it match the SC language

bbailey like the idea - otherwise it implies that you'll have a separate file to do that

<maryjom> POLL: Do you think 1.2.3/1.2.5 should be changed to what is suggested change to use "within the synchronized media"? +1, 0, -1

<loicmn> +1

<PhilDay> +1

<bbailey> +1 pending double check of "within"

<Daniel> +1

bbailey: Not sure if "within" is the right adjective. But it is part of the synchronised media

<bbailey> Audio description is provided for all prerecorded video content in synchronized media.

PhilDay: "as part of the synchronised media"?

<loicmn> I prefer "within"

<bbailey> i'm okay using "within"

<bbailey> +1

PhilDay: Prefer within.

Consensus: we will keep "within"

Next comment from Andrew:

In Page Titled/2.4.2 the new text refers to a title "attribute". In PDF and in Office documents, the title is a property. I'm not aware of any format apart from HTML/SVG where there is a title attribute, and in these the title that this SC refers to is not delivered via that attribute but via the title element. Suggest removing quotes around

"Title" everywhere and either using Property instead of attribute.

<bbailey> synchronized media: audio or video synchronized with another format for presenting information and/or with time-based interactive components...

Suggestion from Andrew is to use title property instead of "title attribute"

bbailey: Agree that property is a more generic term than attribute

<maryjom> POLL: Do you think that the text should be changed regarding ‘“Title” property’? 1) Change as Andrew suggests to ‘Title property’, 2) only change ‘attribute’ to ‘property’, 3) only remove quotes from ‘Title’, or 4) leave as-is with no changes.

1, then 2, then 4, then 3

<loicmn> 1, then 2

<Daniel> 1

<bbailey> (1) then (2) then (3) then (4)

<bbailey> 1 is fine

bbailey: Happy to get rid of the quotes - change vote to 1

3rd comment from Andrew:

In Link Purpose/2.4.4 it seems that the TF has expanded the concept of links to all UI controls that behave like links.

Recommend reverting some of the deleted text and clarifying as follows:

In non-web documents or software, a “link” is any text string or image in the user interface that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)

<maryjom> Link to Issue 775: w3c/wcag2ict#775

We had changed this SC based on input received in issue 775

As it is sometimes difficult to know what is a link

Currently in our latest draft we have note 1

<maryjom> Currently in the editor's draft...Note 1: In non-web documents or software, a “link” is any user interface control that behaves like a hypertext link.

<bbailey> Just an FYI, I did a word search through WCAG 2.2 and the word "attribute" only appears in example notes that mention HTML.

<maryjom> In non-web documents or software, a “link” is any text string or image in the user interface that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)

PhilDay: Prefer the shorter version we had before, but understand Andrew's concern about the deletions now meaning that we now include UI controls.

loicmn: Thinks that we should keep our text. A button is not a link - it does not act like one. But think that we are more flexible in our note - it allows for other things

bbailey: If we include buttons, then we should also include the section about "outside a user control"

Original text that we had (from start of issue 775):

Note 1 (Added) (for non-web software)

In non-web software, a “link” is any text string or image in the user interface outside a user interface control that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)

Then we made it much shorter in latest editor's draft:

NOTE 1 (ADDED)

In non-web documents or software, a “link” is any user interface control that behaves like a hypertext link.

Andrew's proposal is somewhere between the 2:

Recommend reverting some of the deleted text and clarifying as follows:

In non-web documents or software, a “link” is any text string or image in the user interface that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)

<Daniel> 11 September meeting discussion

[maryjom now looking through meeting minutes - link from Daniel above shows the discussion]

bbailey: Andrew's is a bit contradictory - there is no explanation of why OK button is not a link. The original (long) version explained this better

<maryjom> Current editor's draft: In non-web documents or software, a “link” is any user interface control that behaves like a hypertext link.

<maryjom> Andrew's suggested: In non-web documents or software, a “link” is any text string or image in the user interface that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)

Option 1: our long original

Note 1 (Added) (for non-web software)

In non-web software, a “link” is any text string or image in the user interface outside a user interface control that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)

Option 2: our short current editor's draft

<maryjom> Original text before issue 775: In non-web software, a “link” is any text string or image in the user interface outside a user interface control that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)

NOTE 1 (ADDED)

In non-web documents or software, a “link” is any user interface control that behaves like a hypertext link.

Option 3: Andrew's suggestion

Recommend reverting some of the deleted text and clarifying as follows:

In non-web documents or software, a “link” is any text string or image in the user interface that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)

<maryjom> Poll: which do you prefer? 1) Option 1 - current editor's draft, 2) Option 2 - original pre issue 775, 3) Option 3 - Andrew's edits, or 4) something else.

<loicmn> 2

<loicmn> Sorry 1

1, then 2. Not 3. Sorry Andrew!

<bbailey> 1 then 2 then 3

Consensus: we will leave as is in the editor's draft. This also matches what is in EN 301 549

<bbailey> Previous WCAG2ICT (to 2.0): In software, a “link” is any text string or image in the user interface outside a user interface control that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)

loicmn had to step away - so unable to vote for a few minutes

Daniel: Guess that Andrew's main concern is whether OK buttons should be included or not. We should comment on this in our reply.

<bbailey> https://www.w3.org/TR/wcag2ict-20/#navigation-mechanisms-refs

maryjom: We don't think that an OK button is a link.

Daniel: Maybe include "An OK button is not a link" in the comment.

But not add it to the editor's draft

bbailey: Think this was a deliberate change we made, so we should avoid stepping back.

However, the latest guidance somewhat reverses what we said in 2013

<maryjom> DRAFT RESOLUTION: To edit 1.2.3 and 1.2.5 per Andrew's edits, and for 2.4.4, to leave Note 1 as it is in the editor's draft.

<PhilDay> +1

<bbailey> +1

<loicmn> +1

RESOLUTION: To edit 1.2.3 and 1.2.5 per Andrew's edits, and for 2.4.4, to leave Note 1 as it is in the editor's draft.

1.3.6 Identify Purpose (AAA)

Loic's suggestion: w3c/wcag2ict#538 (comment)

Here is my first proposal. First, the notes to "Applying SC 1.3.6 Identify Purpose to Non-Web Documents and Software":

NOTE 1 (ADDED)

This success criterion only applies to non-web documents and software that are implemented using markup languages, and that support programmatically exposing the purpose of user interface components, icons and regions.

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

"Content implemented using markup languages" includes parts of software that use markup internally to define a user interface. Examples of markup languages that are used internally to define a software user interface include but are not limited to: HTML (e.g., in Electron applications or iOS application web views), XAML, XML (e.g., in Android

application layouts), and XUL.

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

See also the Comments on Closed Functionality.

Second, the bullet point in "Problematic for closed":

1.3.6 Identify Purpose - Depends upon information in a programmatically determinable form; in the absence of programmatic capabilities, information on the purpose of user interface components, icons and regions need to be specific and be provided to the user in other modalities (e.g. auditory).

<Zakim> loicmn, you wanted to quickly explain approach

loicmn: When I started working on this took previous ideas on markup languages - so it is based on work from other SCs as well
… Because 1.3.6 is about content developed using markup languages

Any comments or concerns?

Or say if you are not ready to commit

<PhilDay> +1 from me

<bbailey> +1

<maryjom> DRAFT RESOLUTION: For 1.3.6, add the guidance and notes as proposed in issue 1.3.6 by Loic.

<PhilDay> +1

<loicmn> +1

<bbailey> +1

<Daniel> +1

RESOLUTION: For 1.3.6, add the guidance and notes as proposed in issue 1.3.6 by Loic.

1.2.8 Media Alternative (AAA)

maryjom: One quick thing I noticed: how to make things stand out for AAA.
… Created a PR to illustrate a slightly new approach to help differentiate AAA issues

Proposal: w3c/wcag2ict#814

Either add something to the heading, or notate differently to make them stand out

Curious to get input on whether we need to help differentiate these?

Should heading have (Level AAA) added?

<bbailey> +1 to including "AAA" in headings

Daniel: We could do this via scripting if needed.
… No need to add it manually

<loicmn> +1 to including "AAA" in headings

maryjom: We do create the heading for Applying SC XXX

Daniel: was thinking of having it in the main SC heading

<bbailey> I am agnostic about including "Level A" and "Level AA"

<bbailey> +1 wrt concern for lengthy ToC

maryjom: Will add (Levell AAA) and monitor if it makes the ToC too long

There were 2 other proposals made - we will pick them up next meeting (in a fortnight).

<bbailey> fwiw, WCAG 2.2 does NOT include "Level A/AA/AAA" in ToC headings

If you could review prior to the next meeting - just add comments to the issue

<bbailey> i have not done the work i volunteered for ...

Next meeting Thursday 4th December

Then another on December 11th, then break until Thursday January 8th 2026.