Success Criterion Applying SC 2.4.2 Page Titled to Non-Web Documents and Software

[stevefaulkner]

For Applying SC 2.4.2 Page Titled to Non-Web Documents and Software it is unclear whether a title is required for each screen in an app (Software) or for the application as a whole? Likewise is it for a non web document or pages within a non web document?

[stevefaulkner]

It looks like it is possible to set an equivalent of page title for each screen in an app, which then makes sense that it does apply on a screen level rather than application as a whole

[mraccess77]

While it generally is possible to set screen titles - since 2013 WCAG to non-web ICT has applied this as title for the software as a whole. I believe EN 301 549 excepted this from software because it is not possible to force a company to change their app name to something that communicates purpose as that would affect their ability to name the app for business purposes.

: The related web page requirement "Page titled" does not apply to single software programs, but to a specific definition of "sets of software programs" that are extremely rare. NOTE 2: Although the name of a software product could be a sufficient title if it describes the topic or purpose, software names are trademarked and trademark names cannot by law be descriptive names. It is not practical to make software names both unique and descriptive.

[stevefaulkner]

@mraccess77 wrote: "While it generally is possible to set screen titles - since 2013 WCAG to non-web ICT has applied this as title for the software as a whole."

What WCAG to non-web ICT has done historically, while interesting is no reason to continue is it? I don't think the means to add a title to an individual screen in an app has been interoperably supported until fairly recently. I can understand if an on screen heading could be seen as an equivalent, but in cases where there is not one, the provision of a screen title may offer useful information.

[JJdeGroot]

@stevefaulkner I don't think the means to add a title to an individual screen in an app has been interoperably supported until fairly recently.

Since Android 1 you are able to set a title for an Activity (= screen). And since iOS 2 you can set a title for a UIViewController (= screen).

Android 1 was released on September 23, 2008 iOS 2 was released on July 11, 2008

I think almost all other kinds of non-web ICT also have the ability to set a title for individual screens.

@mraccess77 The related web page requirement "Page titled" does not apply to single software programs, but to a specific definition of "sets of software programs" that are extremely rare.

This is written in the EN 301 549, but WCAG2ICT (9 July 2024) states:

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.2 replacing “Web pages” with “non-web documents or software”.

Which is identical to the version of 5 September 2013:

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.2 (also provided below) replacing “Web pages” with “non-web documents or software”.

It looks like Note I in Chapter 11.2.4.2 of the EN 301 549 standard v3.2.1 is incorrect.

The sets of software programs restriction is applied to 2.4.1, 2.4.5, 3.2.3, 3.2.4 and 3.2.6; but not to 2.4.2.

We've also had some discussion about the definition of sets of software programs in the Mobile Accessibility Task Force: https://github.com/w3c/matf/issues/11

The main challenge seems to be defining view or screen.

Once you have a clear definition for screen, you can apply Page Titled to screens, and change sets of software programs to sets of screens to apply Bypass Blocks, Multiple Ways, Consistent Navigation/Identification/Help.

But when applying those success criteria, you run into some new issues, e.g. what would be a mechanism to bypass blocks in non-web ICT.

[bruce-usab]

Discussed on TF call 7-11.

• TF is respectful of 2013 language for 2.0 SC, but we are liberty to make changes (and there have been edits).
• TF agrees with 2013 treatment on this SC.
• No one on call had concerns with EN 301 549 note, but we concurred that it would be out of scope for WCAG2ICT.
• I volunteered to draft a proposed response for TF consideration. That will be after minutes post to list.

[bruce-usab]

PROPOSED draft response:

Thank you @stevefaulkner for the feedback. The TF discussed and we have consensus that 2013 approach is appropriate and sufficient. Please see 2.4.2 Page Titled in the editor's draft.

[stevefaulkner]

@bruce-usab How was consensus reached on this? What factors were taken into account that "2013 approach is appropriate and sufficient." I read the TF discussion you linked to. The discussion appears solely procedural. 

The questions I am pondering: Is this a good decision/interpretation for people with disabilities, if so what data was this decision based on?

[stevefaulkner]

related discussion: https://github.com/w3c/wcag2ict/issues/261

[stevefaulkner]

@JJdeGroot thanks for the info.

Since Android 1 you are able to set a title for an Activity (= screen). And since iOS 2 you can set a title for a UIViewController (= screen).

Android 1 was released on September 23, 2008 iOS 2 was released on July 11, 2008

I think almost all other kinds of non-web ICT also have the ability to set a title for individual screens.

If this is the case why is not practical to transpose SC 2.4.2 Page Titled to apps?

[bruce-usab]

@stevefaulkner

How was consensus reached on this?

No one on the call expressed concern for closing this issue with a response only. The TF gets at consensus via survey or vote/poll during a call. The minutes reflect that process for some PRs.

What factors were taken into account that "2013 approach is appropriate and sufficient."

That is my paraphrase of the conversation. Would you be more comfortable with "2013 approach is good enough"?

I read the TF discussion you linked to. The discussion appears solely procedural.

It was not a long conversation, but I respectfully disagree with the characterization of "solely procedural".

The questions I am pondering: Is this a good decision/interpretation for people with disabilities, if so what data was this decision based on?

I am of the opinion that @maryjom comments on related discussion 261 are applicable to this issue.

The TF will not be modifying the handling of these SC/this interpretation in this round of updates which are focused on incorporating newer versions of WCAG... This TF update was not instituted to re-examine the interpretations previously negotiated over months. That said, other standards could choose to modify the WCAG SC to be more specific/appropriate for non-web software.

[maryjom]

I had gone through a number of the minutes of the 2013 WCAG2ICT Task Force discussions to remind myself of the decision to equate a "web page" with a "software program". This came from an evolution of discussions over a long period of time. In short, the unit of conformance that one makes claims against for meeting accessibility requirements for the Web is a "web page" and for non-web software it is a "software program". Therefore, WCAG2ICT applies the SC to the software program (or "set of software programs", on those SC that are applied to websites or sets of web pages). This provides a consistent word substitution for all SCs.

While some software platforms may support providing a "view" and/or "window" title, WCAG2ICT covers a wide variety of software - from software on products with closed functionality (think point-of-sale, printers, VR software applications, etc.) to software on mobile devices and desktops. One can't say that across the board that ALL software can (or should) support a meaningful title for every "view" or "screen" of all types of software.

The same problem exists in WCAG where applications are often a single URL. WCAG does not apply this requirement to dialog boxes, flyovers, popup content, sliding panels, or other overlays which could be considered views - even though there are web capabilities to provide some form of title or heading to serve as a title. IMO, it would necessitate a normative change to either add scoping of the requirement to those aspects or a new requirement to do so which would come with its own set of exceptions and caveats where the SC would be difficult or not make sense to apply. WCAG2ICT can't suggest any normative changes, so it would be up to other standards to do that part.

As an aside...the EN is incorrect in its note 1 that says:

NOTE 1: The related web page requirement "Page titled" does not apply to single software programs, but to a specific definition of "sets of software programs" that are extremely rare.

WCAG2ICT did not interpret 2.4.2 to be applied to "sets of software" as noted by the word substitutions to apply the success criterion to "non-web documents or software".

[stevefaulkner]

Evinced open source Mobile Content Accessibility Guidelines (MCAG) 3.1.1. Screen Titled

[LJWatson]

@maryjom, thanks for doing the archaeology to surface how the 2013 decision came to be made. I can't help but feel that "consistent word substitution" is not a good enough reason for deciding against something that we know is beneficial to users though. Would it really be that difficult to acknowledge that in the case of apps it is possible to programmatically identify a screen title, given that we know it does help users?

[maryjom]

@LJWatson There was more to the analysis than simply consistency. Another argument was regarding the unit of conformity equivalent to a web page - which is a software application as a whole. The 2013 Task Force also analyzed a number of scenarios, types of software, parts of software, etc. for several success criteria. Unfortunately, I don't have any access to any of those examples or scenarios we reviewed at that time, and only have access to the meeting minutes and survey results (which linked to either a wiki or some other resource for review content - all are broken links). The work spaces we worked in are no longer available. Therefore, I cannot comment fully on those conversations without the full information.

From the meeting minutes and survey results reviewing those items, one can see there were some WCAG success criteria that, while useful to persons with disabilities, were not supported across all types of software and all types of "views" or "interaction contexts" which is the term I think we were considering at the time. In fact, there was much debate and no consensus over what to call a "view", how a "view" might be defined, or what might or might not be considered a "view" in the specific examples we reviewed.

Since WCAG only covers the web, it hasn't built into its normative language the appropriate caveats, exceptions, or guidance for native software. WCAG2ICT is specifically limited in our scope of work where we cannot make (or suggest) any such normative changes to make WCAG Success Criteria fit more broadly to all non-web software technologies. Additionally, this iteration of the Task Force was not scoped to re-examine all of the work or decisions made by the previous task force. It was to add WCAG 2.1 and 2.2 success criteria and definitions, address 3 existing open issues, and provide more information on the Success Criteria that are problematic for closed functionality.

I do not disagree that having window titles, headings, etc. to indicate the topic of a "view" can be useful - especially to persons with disabilities and doing so is generally a good design and usability practice. However, there are also many cases where titles are not necessary or not supportable by the software technology. In WCAG2ICT, we could perhaps indicate that this is a best practice where the technology supports it, but beyond that, saying that 2.4.2 should be a requirement for all "views" within all software goes too far. WCAG2ICT cannot add the necessary scoping or exceptions - that's normative and beyond our stated scope of work.

I would hate to see a requirement made for ALL software to meet this SC, where it may not be technically feasible to implement or where the way the software is designed the purpose of the view is inherently obvious. It would unintentionally cause a lot of software to fail and I found a lot of examples in software applications and in platform software that would fail if this was made a requirement.

[stevefaulkner]

How does this square with Section 508 not exempting 2.4.2 for Software? A related question, how are web views treated? Are they also exempt?

[stevefaulkner]

@maryjom wrote:

WCAG2ICT is specifically limited in our scope of work where we cannot make (or suggest) any such normative changes to make WCAG Success Criteria fit more broadly to all non-web software technologies.

Right, as the doc is informative, how does that effect the subject in question?

[maryjom]

How does this square with Section 508 not exempting 2.4.2 for Software? A related question, how are web views treated? Are they also exempt?

508 is applying 2.4.2 as the 2013 WCAG2ICT interpreted to non-web software - applying it to the software program as a whole, not individual views within the program.

For the EN 301 549, I don't exactly know why that standard excepted 2.4.2 altogether, though their notes seem to try to explain why this was made a void requirement. Notes quoted below:

NOTE 1: The related web page requirement "Page titled" does not apply to single software programs, but to a specific definition of "sets of software programs" that are extremely rare.

NOTE 2: Although the name of a software product could be a sufficient title if it describes the topic or purpose, software names are trademarked and trademark names cannot by law be descriptive names. It is not practical to make software names both unique and descriptive.

The first note is incorrect. The second note goes beyond WCAG talking about "unique" descriptive names - as the "unique" part is not required by SC 2.4.2. Additionally, even if a software name is a trademark name that may not be actual words, IMO it is descriptive, as it indicates that the window is that particular application - identifying its purpose. Some may disagree with that, but many applications add to their trademark name to indicate what file you're working with, etc. which helps the description be more meaningful. Doing so helps identify a particular instance or window when an application supports multiple windows being opened (such as a document editor which allows editing multiple different documents - each in its own window.)

Neither 508 nor the EN describe how web views are treated, and do not state any exemptions, techniques or clarifications. I think this is a major area of missing guidance and not something in scope for WCAG2ICT.

[JJdeGroot]

As an aside...the EN is incorrect in its note 1 that says:

NOTE 1: The related web page requirement "Page titled" does not apply to single software programs, but to a specific definition of "sets of software programs" that are extremely rare.

WCAG2ICT did not interpret 2.4.2 to be applied to "sets of software" as noted by the word substitutions to apply the success criterion to "non-web documents or software".

Created issue: https://labs.etsi.org/rep/HF/en301549/-/issues/275

[maryjom]

@maryjom wrote:

WCAG2ICT is specifically limited in our scope of work where we cannot make (or suggest) any such normative changes to make WCAG Success Criteria fit more broadly to all non-web software technologies.

Right, as the doc is informative, how does that effect the subject in question?

Regarding this question - maybe not in the initial post, but in subsequent posts it was indicated this SC should be applied to individual "views" within non-web documents and software and those comments were directed to that rabbit hole.

For the initial question...In reading the notes in the WCAG2ICT guidance, NOTE 1 seems to give a fairly clear example of applying this SC as the Name of the software or the name of the document. I've been drafting a potential extra note that indicates it's a "best practice" to have a title to different views of content, such as dialogs. Would this help?

[stevefaulkner]

Hi @maryjom

but in subsequent posts it was indicated this SC should be applied to individual "views" within non-web documents and software and those comments were directed to that rabbit hole.

This should be interpreted as a non-normative should :-)

I've been drafting a potential extra note that indicates it's a "best practice" to have a title to different views of content, such as dialogs. Would this help?

certainly, but as the ICT2WCAG is not a normative document aren't all the statements in it effectively best practice only?

It is unclear to me why the following is applicable to screens/views although not explicitly stated

Applying SC 2.4.3 Focus Order to Non-Web Documents and Software This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.3 replacing “a Web page” with “non-web documents or software”.

With this substitution, it would read:

2.4.3 Focus Order: If [non-web documents or software] can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

while the same wording is used for 2.4.2 but changes the scope and intent of 2.4.2 to not apply to individual "pages"

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.2 replacing “Web pages” with “non-web documents or software”.

With this substitution, it would read:

2.4.2 Page Titled: [Non-web documents or software] have titles that describe topic or purpose.

The Understanding SC 2.4.2 document (itself non normative) refers to distinct pages/views for SPAs which would work also for apps no?

In cases such as Single Page Applications (SPAs), where various distinct pages/views are all nominally served from the same URI and the content of the page is changed dynamically, the title of the page should also be changed dynamically to reflect the content or topic of the current view.

could be rewritten to apply to apps, like this

In cases such as Applications, where various distinct screens/views are all are contained within the same application the title of the view should also be changed dynamically to reflect the content or topic of the current view.

[mapluke]

I acknowledge that Note 1 in EN 301 549 that referred to sets of software was not correct, although as the above discussions about views, it is meaningful labelling of views within a software application that is really the issue where what 2.4.2 calls for would be most beneficial to users.

The fundamental concern was, and still remains, that in reality the name of a software application very rarely "describe topic or purpose" of the application. The names of some apps can give a heavy clue to what the purpose of that app is - what you might be able to use it for, but the vast majority do not seem to. A description of the purpose of most office suite apps might be "content creation app", "word processor", "spreadsheet", etc. But two wordprocessing apps from different suppliers have names that are trademarks, and these have to be unique. So, @maryjom is 100% correct in saying that 2.4.2 does not require the names to be unique, but trademark law does. So, this explains the intent of the EN 301 549 Note 2.

@JJdeGroot has, as he said, created an issue on this in the EN 301 549 GitLab project, and we will definitely reconsider what we should do with 2.4.2 applied to software, we certainly need to change what we currently have. It is possible that we might choose to include 2.4.2 for software, and then perhaps add a note such as the one that @stevefaulkner suggests about being '"best practice" to have a title to different views of content, such as dialogs'.

Perhaps those who would then have to apply this requirement would be far less strict than me, and wouldn't fail almost every software application on the market for having a name that in no way "describes" the purpose of that app!

[mapluke]

I acknowledge that Note 1 in EN 301 549 that referred to sets of software was not correct, although as the above discussions about views agree, it is meaningful labelling of views within a software application what would be genuinely beneficial to users.

The fundamental concern was, and still remains, that in reality the name of a software application very rarely "describe topic or purpose" of the application. The names of some apps can give a heavy clue to what the purpose of that app is - what you might be able to use it for, but the vast majority do not seem to. A description of the purpose of most office suite apps might be "content creation app", "word processor", "spreadsheet", etc. But two wordprocessing apps from different suppliers have names that are trademarks, and these have to be unique. So, @maryjom is 100% correct in saying that 2.4.2 does not require the names to be unique, but trademark law does. So, this explains the intent of the EN 301 549 Note 2.

@JJdeGroot has, as he said, created an issue on this in the EN 301 549 GitLab project, and we will definitely reconsider what we should do with 2.4.2 applied to software, we certainly need to change what we currently have. It is possible that we might choose to include 2.4.2 for software, and then perhaps add a note such as the one that @stevefaulkner suggests about being '"best practice" to have a title to different views of content, such as dialogs'.

Perhaps those who would then have to apply this requirement would be far less strict than me and wouldn't fail almost every software application on the market for having names that in no way "describe" the purpose of the app!

[maryjom]

I have a feeling that when this SC was first born, SC 2.4.2 was intended so that users could:

1. tell that when they used a link that it went to the right page, and
2. tell the difference between different browser windows (and eventually tabs) so that switching between web pages was easier to do - each was identifiable. At that point in time, if you didn't have a web page title, the window title used to be something like "Netscape" or for tabs something like "Page 1", "Page 2", etc. for however many Netscape instances you had displaying pages without titles. LOL - Used a dated reference because I've been in accessibility that long (before WCAG was thought of). These generic titles wouldn't be so helpful to users trying to find which window or tab had their desired target web page in it...and an SC was born to address it.

Now we've advanced a number of years with single-page applications but this SC's normative language hasn't evolved to properly handle the change in technology - it was restricted from doing so for backwards compatibility. Instead, the understanding added a "should" statement to cover single-page applications because it couldn't say "must" - which would change or extend the normative language since "Web page" is defined as a single URL.

I've drafted a potential note to add to WCAG2ICT which aligns with the "best practice" language we use elsewhere in the document:

NOTE: Although not required by this success criterion, ensuring that individual windows or screens have a title that describes the topic or purpose addresses the user needs identified in the Understanding Success Criterion 2.4.2 Intent section, and is generally considered a best practice.

The Task Force has not yet reviewed the above statement, but I'm wondering if this seems like a reasonable addition.

[maryjom]

@mapluke Trademark law requires applications to have unique names, but not window titles. So I'm not sure I understand why an accessibility standard is working to enforce trademark law. If multiple instances of the same trademarked application are open on a computer, that doesn't pose a trademark issue. Unless that application modifies the window title to something unique, a user can't tell the difference between the various windows, so it's definitely a best practice to give each a unique name if at all possible (and when it makes sense to do).

[mapluke]

@maryjom after many years since the mapping was first made, I have finally realised that you and others have interpreted the meaning of what "title" of software means in an entirely different way to how I have always understood it! It's absolutely nothing to do with those who have written EN 301 549 wanting an accessibility standard "working to enforce trademark law"!

I, and I assume all those who reviewed and agreed EN 301 549, have always interpreted the meaning of the "title" of non-web software as meaning the product name. It is now clear that you, and many other reviewers in this issue, are interpreting it to mean the title of windows generated by the software!

I, of course, entirely agree that, where possible, it is best practice to give a unique name to indicate what that app is currently doing/presenting. However, after a very quick check on my PC I have found that:

• a) some apps only present the product name, which almost never adequately describes what the purpose of the app is (because it is a trademark);
• b) some apps present both the product name plus the relevant context information that shows what that view is about;
• c) some apps only present the context information that shows what that view is about in the title and do not explicitly name the app (but maybe add a logo for braning);
• d) many others present relevant context information that shows what that view is about, but very often not in the title;.

So, am I correct in assuming that you believe that the requirement is requiring a solution like b) or c), but not a) or d). If so, then I would entirely agree that this is exactly what is wanted, but I have never read the WCAG2ICT mapping to be asking for anything remotely like that!

Unless:

• I, and the others who agreed to not include 2.4.2 for software in EN 301 549, all have a similar unique interpretation of what the WCAG2ICT mapping says, and that we would not expect others to ever fall into the same trap;
• and that nobody who was involved in approving EN 301 549 queried this decision and presented/explained the alternative interpretation that you have made;

there will need to be, at the very least, a very clear note added to this requirement to ensure that it is "correctly" understood by all those who encounter it. I am not sure whether it is entirely appropriate to cover all this in a note, because to me the above interpretation goes well beyond what the words of the requirement appear to say.

[mitchellevan]

I agree that page-like screens ought to have descriptive titles when they can. However, in the issue discussion so far, I see appropriate attention paid to typical mobile apps, but not enough for other kinds of apps. Our challenge is to stretch a nine-word, web-centric criterion to address a more diverse non-web reality:

• In some non-web platforms and document technologies, it’s common to have screens that look like pages and have titles for those screens. Examples: iOS and iPadOS apps, Android apps, PowerPoint documents.
• In others it’s not possible. Examples: most console games; PDF documents.
• In others it’s borderline possible, depending on the content. Which smart TV apps would we require to have page titles? Which kinds of container objects in native Windows apps?

I propose a new Note, something like the following:

Note: When software content is presented as separate screens that resemble pages, and the technology supports a separate title for each screen, it is a best practice to provide screen titles and ensure that they describe the topic or purpose of each screen. Where screen titles are provided, a title for the overall software program is still necessary.

If somebody can propose a word substitution for the normative text, and/or notes, which don't change WCAG (which WCAG2ICT can't do) and appropriately address the real-world diversity of platforms and content, then it would be a solid win for users. Unfortunately I am dubious that that would be feasible under the constraints.

[maryjom]

@mapluke I agree with the assessment from @mitchellevan on this. With the widely diverse space of non-web software, it would be difficult to definitively carve out the scoping and application of this SC to different "views" or "screens" (and difficult to unambiguously define that term). Whether it is appropriate to require a title in all "views" or "screens" of all software applications, and whether it is technically feasible on all software platforms, leaves a lot of unanswered questions. So my preference is to limit this to indicate that where it is supported, it can help make the application more usable, but is not a requirement of this SC.

Your four examples a) through d) seem to cover the examples I was thinking about in my earlier comment. However, I don't think this SC requires b) or c) but those are helpful to provide all users with appropriate context to confidently switch between multiple instances of a software application. However, it may be implemented using different methods and not necessarily from a "title" attribute for each window. Examples include:

• MacOS has different methods of indicating the active application and surfacing a "title" and the identifier for the instance of the application. The name of the active (focused) application appears in the application menu bar at the top of the display (the trademarked application name only). When multiple application instances exist (files in a document editor, browser windows), the user accesses them using the context menu for the application from the dock. Those are identified by the document name, the title of the active tab's web page, etc.
• iPadOS and iOS only allow one instance of a particular application to be active at a time, so the name of the app is the title which appears in the application switcher screen. In a document editor, if a document was opened recently, that file name also appears in the app switcher view, but in different typeface, so it's likely a different attribute obtained from the application - not the application title.
• Small screen devices (like a watch) don't have space for visible application titles. There's icons for switching, and under the covers they have alt text on them so they can be voiced. That's how the app is identified.

Other software platforms could have other ways of surfacing identifiers of for individual instances of the same software application. I would not recommend changing this SC to alter what is required.

Regarding the first example you provided:

a) some apps only present the product name, which almost never adequately describes what the purpose of the app is (because it is a trademark);

Yes, that's true. Even the browser titles aren't "Firefox web browser" or "Chrome browser". The App store provides that extra info. Yes, new users may initially have difficulty remembering what these apps are, but over time these names become recognizable along with their application icon. I'm not sure if, as a user, I'd want that additional information to be required of all software applications.

[bruce-usab]

Discussed on call 8/1, socializing Mitch's proposed note above.

[bruce-usab]

Noting that @JJdeGroot (of MATF) joined call today 8/8 and we discussed more.

[maryjom]

Appreciate your comment @stevefaulkner. The WCAG2ICT Task Force has agreed to add a note to the editor’s draft to indicate that when an application has different views or windows it is a best practice for them to have a title. The exact verbiage we have added to the section Applying 2.4.2 Page Titled to Non-web Documents and Software is:

NOTE 2: Although not required by this success criterion, ensuring that individual windows or screens have a title (where that title describes the topic or purpose) addresses the user needs identified in the Understanding Success Criterion 2.4.2 Intent section, and is generally considered a best practice.

You can read the change in-context in the editor's draft in the section titled Applying SC 2.4.2 Page Titled to Non-web Documents and Software.