Meeting minutes
<ChrisLoiselle> Agenda: Announcements
<ChrisLoiselle> Agenda: Issue 627: 2.4.2 Page Titled PR #626
<ChrisLoiselle> Agenda: Work through edits on 2.4.2 Page Title Issue 627 Google Doc
<ChrisLoiselle> Agenda: Analysis for SC language changes Google Sheet
<ChrisLoiselle> Agenda: Announcements
<ChrisLoiselle> For announcements, announce that the WCAG2Mobile FPWD published yesterday 6 May.
Announcements
EN 301 549 - Gregg mentioned that the next draft is coming soon
Publication of WCAG2Mobile - 1st mobile draft was published yesterday.
Issue 627: 2.4.2 Page Titled PR #626
<ChrisLoiselle> https://
Work through edits on 2.4.2 Page Title Issue 627 Google Doc
<bruce> Also, 2.1 republished https://
bruce: Had a hard time fitting the updates into the sources doc from google doc - so been doing edits in PR instead. Are we going to end up with 2 versions of 2.4.2 or just 1 version? Also are we renaming 2.4.2?
ChrisLoiselle: Google doc is for brainstorming ideas during call, then update PR after the call. If it is too confusing having 2 sources we could combine
maryjom: Qs for bruce. Did you incorporate proposal 2 or 3 into the PR?
maryjom: Gregg has also added another proposal which is different
bruce: Updated PR that was done 2 weeks ago to incorporate proposal 2. Had issue with heading levels
bruce: If all happy with proposal 2, is the PR close enough?
[Chris sharing screen to show PR 626 split screen with the google doc]
<ChrisLoiselle> w3c/
maryjom: Consider 2.4.1 - we did different things for software and documents. We didn't have separate headings, just parenthetic statements
bruce: Couldn't use this model - as we don't have the word substitution for software
bruce: suggests using separate headings for applying to documents vs software - to make it clearer
maryjom: This change would be problematic for 2.4.1 where notes are split between the 2
<bruce> https://
PhilDay: Think the separate headings approach that Bruce has proposed is cleaner than the current parenthetic statements approach that we previously used.
ChrisLoiselle & maryjom - does involve quite a lot of editorial work to do this
maryjom: Suggest we put this to the group via a survey and compare the 2 approaches
… have an alternative PR with Gregg's proposal with the other formatting
<bruce> Sorry, that was wrong PR!
<bruce> https://
ACTION: create alternative PR, then issue survey comparing the different approaches. maryjom to do this.
bruce: Does it make sense to have 2 subheadings rather than 1 (H6 vs H5)?
bruce: Second question is what we do with short headings? Propose keep the same, and just change the text following
maryjom: May need to replace the word page in the short name
… (show the word substitution)
… This was what the ETSI committee did - change the short name to include word substitution so it no longer referred to Page (which is web-specific language).
bruce: If we do this word substitution we lose all the words that were in the WCAG 2.2 SC - none of these appear in the non-web SC title
<Zakim> PhilDay, you wanted to say parenthetic still works
GreggVan: Proposed language doesn't make sense to me. If name is defined as being descriptive - just stating every product's name should be its name
… What does the title of the product mean?
<bruce> Change would be: 2.4.2 Software Names: [Non-web software] have names that provide description identification.
GreggVan: Intent of this provision - when you change pages (URLs) - that the user has an idea which page they have landed on.
… Could apply to each "window" in software - but not all software has windows.
… If a product has windows, then each window should be differentiable
… But if we can't talk about windows - then just say it doesn't apply to software
ChrisLoiselle: Could add this to a survey
… Then we could get some consensus
<Zakim> bruce, you wanted to make change to handle in PR 626
bruce: [looking at deploy preview on PR 626]
<ChrisLoiselle> https://
bruce: what this proposal would have "Software named: Non-web software have names that provide description identification.
GreggVan: What would be the descriptive identification for the program Shazam?
bruce: Shazam is meaningful for the person that is trying to change focus.
Mike_Pluke: Fundamental problem - descriptive identification doesn't add much more. Name is fine - just stop there as it's not really descriptive - it doesn't describe a topic or purpose. Name is an identifier. Not a descriptive identifier
ChrisLoiselle: Often have some sort of "About" section to get more information about the product - which could help the user to identify more about the product - so we could refer to context specific help for this
<Zakim> PhilDay, you wanted to suggest unique identifier rather than descriptive
<ChrisLoiselle> Phil: Unique identifier could be an option
Mike_Pluke: have no problem with unique identifier
… And swapping windows - there is often a purpose for changing windows
<Zakim> loicmn, you wanted to suggest that unique identifier does not work
loicmn: We cannot require unique names - as they don't know all the other developers in the world.
loicmn: Suggest we just stop and say it doesn't apply.
<bruce> Maybe: 2.4.2 Software Names: [Non-web software] have names that provide meaningful identification.
loicmn: We could add a requirement to the platform to have programmatic access to the name
<Zakim> GreggVan, you wanted to say how about "where software has titles attributes for windows or screens, titles are provided that ...
GreggVan: "where software has titles attributes for windows or screens, titles are provided that ..."
… if there is a way to title them, then make these titles unique or differentiable within this software.
<loicmn> +1 to Gregg's proposal
<Mike_Pluke> +1 also
<bruce> -1 to "unique identify" per Loic's concern that author cannot know their software name is unique
<ChrisLoiselle> https://
<bruce> Note 2 is what we had before
Deploy preview - NOTE 2 (ADDED) addresses some of this concern
… Captures best practice
GreggVan: Would add something to NOTE 2 (ADDED)
maryjom: Notes would need adjusting - NOTE 1 would need to be removed altogether as we are not using Title.
… departing from WCAG so don't need to refer to Intent
… And note 2 also uses "Title" so we should reword this.
ChrisLoiselle: We may also have to not talk about "word substitution" as it is not quite accurate
We are substituting the whole SC - not just a word within it
<GreggVan> Although not required by this success criterion, ensuring that apps that have individual windows or screens that support a title or name for the window or screen, provide a title/name that allows unique identification, and where possible describes the topic or purpose). This would address the user needs identified in the Understanding Success Criterion 2.4.2 Intent section, and is generally considered a best practice.
<GreggVan> or better yet " The does not apply directly to software through simple word substutio but ensuring that apps that have individual windows or screens that support a title or name for the window or screen, provide a title/name that allows unique identification, and where possible describes the topic or purpose). This would address the user needs identified in the Understanding Success Criterion 2.4.2 Intent section, and is generally
<GreggVan> considered a best practice
bruce: These notes are what we currently have in WCAG2ICT. Part of what I was trying to do was reuse as much as we could - to avoid concerns from others
<GreggVan> The does not apply directly to software through simple word substutio but ensuring that apps that have individual windows or screens that support a title or name for the window or screen, require that software provide a title/name that allows unique identification, and where possible describes the topic or purpose). This would address the user needs identified in the Understanding Success Criterion 2.4.2 Intent section, and is generally
bruce: Think it is OK for notes to refer to Title, even if we have substituted Name for title - I don't think it is contradictory.
GreggVan: instead of all the notes - just have the statement above
<GreggVan> The does not apply directly to software through simple word substutio but ensuring that apps that have individual windows or screens that support a title or name for the window or screen, be required to provide a title/name that allows unique identification, and where possible describes the topic or purpose). This would address the user needs identified in the Understanding Success Criterion 2.4.2 Intent section, and is generally
<maryjom> This does not apply directly to software through simple word substitution. However, ensuring that software applicationss that have individual windows or screens that support a title or name for the window or screen, require that software provide a title/name that allows unique identification (and, where possible, describes the topic or purpose).
<maryjom> This would address the user needs identified in the Understanding Success Criterion 2.4.2 Intent section, and is generally considered a best practice.
<bbailey> Notes for 2.4.2 in PR 626 are unchanged from 15 November 2024 pub.
ChrisLoiselle: Best thing to do is bring this proposal in a survey for comment from the larger TF
<bbailey> I think it is okay for notes to refer to title, even though the suggested replacement uses title.
GreggVan: Quick question. Mike has 24 hours to do final tweak on EN 301 549.
… Then not revising until later in summer.
Mike_Pluke: Not convinced we've got enough that is finalised yet - so leave it for now in EN
maryjom: 1 quick question. If we do get language together - would we be able to submit as a comment on the next official version?
Mike_Pluke: Yes we can add from a comment
GreggVan: This is the last chance for comments. And please do not wait until the last day for comments.