Meeting minutes
<Zakim> Daniel, you wanted to say she should be good to go now
<bruce> That's great about Jen!
<bruce> Good to know that W3C publishing is not limited to one day per week!
PR 626: w3c/
Google doc link: https://
Issue 627: 2.4.2 Page Titled PR #626
chris: Mary Jo reviewed PR 627 a few days ago, Bruce and gregg also commented
<ChrisLoiselle> Mary Jo: Name of document or within the document and where title would be appropriate?
<ChrisLoiselle> Mary Jo: I think splitting non web documents and software would be right thing to do.
gregg: The title of the document is what is within the document.
… not the file name.
<bruce> Most non-web documents support title metadata, and yes, I agree we should use title for non-web documents.
gregg: software cannot and the name of the software doesn't describe the topic or purpose.
… We can't have a note to change the meaning of the SC. The SC language would have to change more substantively.
… for documents it's almost always true that there is a title or some text that describes the topic or purpose of the document.
<bruce> Please ignore what I have in the PR about using filename for titles on non-web documents. I didn't understand that I had the liberty to split documents from software.
<Zakim> bruce, you wanted to say please ignore what i have in the PR about using filename for titles on non-web documents
Bruce: Please ignore the text about the name of the document being used. All for splitting documents from software and treating them differently.
Gregg: Then we can say that the SC doesn't apply to software. The whole purpose is to label the window and software doesn't necessarily have windows.
Mike: Gregg has said this the way this is understood by the group working on the EN 301 549
<Zakim> bruce, you wanted to suggest switching to Google doc then
bruce: We have addressed comments in the PR and so we can switch to the Google document
<ChrisLoiselle> https://
bruce: don't think note 1 makes sense any more for non-web documents.
<ChrisLoiselle> POLL: Do we agree as a group that 2.4.2 page titled applies to non web documents and not for software? 1 for yes, 2 for no
<bruce> 1
<PhilDay> 1
<GreggVan> 1
<LauraM> 1
<Mike_Pluke> 1
<Sam> 1
1
<ChrisLoiselle> 1
<ChrisLoiselle> Mary Jo: In web, title is in reference to tab name.
Gregg: Want to make sure what we have in WCAG2ICT doesn't contradict what's in the understanding.
Bruce: Agree that Note 1 isn't needed.
Gregg: only 5-10% of Word users know where to put the title.
Bruce: The first line in a document isn't programmatically a title.
Gregg: AI can solve that and have a script to reliably pick up a title. If we're writing for the future.
Bruce & Gregg agree no note 1.
Chris: Question on the Google doc - word substitutions should you use "Non-web documents" or "Documents"?
gregg: Should be consistent with other SCs where we use "Non-web Documents"
chris: Agree to remove Note 1.
Gregg: Does WCAG 2.2 have any notes in the original text?
Mary Jo: No, it doesn't
Gregg: For software do we need to provide a rationale?
Chris: Reads out the proposed text.
<ChrisLoiselle> Mary Jo: For non web software, would possibly propose new SC?
<ChrisLoiselle> Mary Jo: We can propose substantial word substitutions per our charter.
<ChrisLoiselle> ... Window and unique per instance
<ChrisLoiselle> Gregg: Introduction of views and windows. If a system has windows or views and if...then they should be X
gregg: Yes, you'd have to introduce the notion of Windows, but there could be a requirement - if you can have different windows or screens that each have a unique name.
<Sam> screens is a hardware based requirement?
There are a lot of people that say it's wrong that Software Titled isn't a requirement.
Daniel: The proposal saying it shouldn't be applied as written to non-web software. There may be some other way to say that.
<bruce> Good catch on "screens".
Gregg: "Screens" could be used so then the mobile aspect can get looped in.
<bruce> -1 to Daniel -- I think its very important to say "should not apply" without equivocation
<GreggVan> Where software is in an environment that supports windows or views (as in mobile apps) and there is a way to provide a programmatically determinable unique name for each, each window or view is provided with a unique human readable view that can be used to distinguish them from each other.
<bruce> PhilDay please something stronger than "difficult"
<GreggVan> Where software is in an environment that supports windows or pages/screens (as in mobile apps) and there is a way to provide a programmatically determinable unique name for each, each window or view is provided with a unique human readable view that can be used to distinguish them from each other.
Sam: Bringing up "views" is a substantial change that would need some scaffolding - like definitions. We could simply go with more consistent text "problematic".
<bruce> i think i am okay with "problematic"
<GreggVan> Where software is in an environment that supports windows or pages/screens (as in mobile apps) and there is a way to provide a programmatically determinable unique name for each, each window or page/screen is provided with a unique human readable name that can be used to distinguish them from each other.
<Zakim> PhilDay, you wanted to suggest This SC may be difficult to apply to non-web software...
Laura: We're making this more complicated for people.
<ChrisLoiselle> From Gregg: Where software is in an environment that supports windows or pages/screens (as in mobile apps) and there is a way to provide a programmatically determinable unique name for each, each window or page/screen is provided with a unique human readable name that can be used to distinguish them from each other.
Gregg: If we want to have a rationale, what I've put in IRC explains it.
Gregg: That way when a user wants to switch around there is a unique name that helps them choose the right window.
Laura: The more casual description is more understandable.
… want to make sure the original intention is captured in an understandable way.
ChrisLoiselle: May be able to add Gregg's explanation after the first paragraph in proposal 2 in the Google doc.
<Zakim> bruce, you wanted to ask "fundamental alteration" rather than "problematic" ? and to ask "fundamental alteration" rather than "problematic" ?
bruce: We should say something "clean" about it. Don't think the caveat of windowed environment should be included.
GreggVan There are things that don't have any window and the user can't switch between anything so a title isn't needed.
… this is in there to support AT users.
If you're in an app that doesn't have but one screen, it doesn't make sense to require it.
<GreggVan> For software direct application of xxxxx is problemmatic. We recommend something along the line of Where software is in an environment that supports windows or pages/screens (as in mobile apps) and there is a way to provide a programmatically determinable unique name for each, each window or page/screen is provided with a unique human readable name that can be used to distinguish them from each other.
sam: This is the dance we have with how we phrase things. I don't think the Windows environment is covered anywhere.
… There has to be some caveats where there isn't a windowed environment.
bruce: There's still a name - even on screens for ATMs where there are screens that really should have a name.
… a product name
<Zakim> bruce, you wanted to say i don't agree product name need not be available for non-windowed softward
Gregg: For accessibility, the name is for the screen reader. For an ATM situation, is the name of the app or product necessary to use the product. Not really.
… you may want to know what bank you're at, but that's not the name of the app.
sam: Agree with Gregg. ATMs or Point-of-sale machines don't really need a name. The context of where it is used makes it obvious.
Bruce: Disagrees that when speech mode is turned on, the original screen may not be announced. Maybe a kiosk does multiple things and the user would need to know which aspect they're using.
… don't think this should be limited to windowing apps.
Gregg: Turn on speech and you're on the home screen. The existing requirements say the screen needs to be read. What's on the screen is never the name of the software, it's the name of the bank or the function you're doing. The name of the software wouldn't be helpful.
<bruce> bank name is name and is providing descriptive identification
LauraM "Never" is a broad statement. When speech is activated on a Kiosk, the screen saver (which has the bank info) will be gone and won't be spoken.
… prefers the language is simpler without caveats.
Gregg: If the splash screen isn't spoken already then it's a failure that not all info on the screen is spoken.
Daniel: On the web it's the page title which describes topic or purpose - this may be met by relying on other accessibility requirements in some software that doesn't have the ability to have titles.
Chris: We'll have to continue formulating proposals in the Google doc for next week.
<Zakim> PhilDay, you wanted to say closed systems are not a good example here - there is no way of swapping windows/apps/views/modes
PhilDay Closed systems aren't an appropriate application of this SC. You can't switch windows in a closed system.