manifest: title about wpub HOT 34 CLOSED

@dauwhe will be able to answer this comprehensively more clearly than I will, partly because this is so fundamental to the definition of a "publication" that I find it difficult to break out the rationale without risking a return to the lexicographic arguments we need to avoid here for pragmatic reasons. However, here is the accessibility-centric answer, which is only a tiny subset of the bigger answer.

WCAG 2.4.2 is addressing individual web pages, not publications. However, the SC is no less vital from the standpoint of a coherent publication.

To answer your precise question:

1. It assists the user,. Without it, the user needs to access the content to know what the publication is.

The intent of this Success Criterion is to help users find content and orient themselves within it by ensuring that each Web page has a descriptive title. Titles identify the current location without requiring users to read or interpret page content. When titles appear in site maps or lists of search results, users can more quickly identify the content they need. User agents make the title of the page easily available to the user for identifying the page. For instance, a user agent may display the page title in the window title bar or as the name of the tab containing the page.

2. It also and assists the UA and AT in assisting the user. For example, per EPUB Accessibility Techniques,

When authoring an EPUB Publication each EPUB Content Document also requires a descriptive title that describes its content. If not provided, Assistive Technologies often will announce the name of the file to users.

EPUB Accessibility actually uses title in its example of how accessibility needs to apply to a publication as a whole, not merely the component documents:

Consequently, when evaluating the accessibility of an EPUB Publication, individual pages — or Content Documents, as they are known in EPUB nomenclature — cannot be reviewed in isolation. Rather, their overall accessibility as parts of a larger work also has to be evaluated.

For example, it is not sufficient for individual Content Documents to have a logical reading order if the publication presents them in the wrong order. Likewise, including a title for every Content Document is complementary to providing a title for the publication: the overall accessibility is affected if either is missing.

from wpub.

@lrosenthol you're going to have to explain "ad-hoc publication" as I'm not sure why you'd insist that title not be required for a publication. The act of publishing is naming a collection of stuff.

If there is no title, what do you propose is displayed/heard/presented in a listing of publications?

from wpub.

@deborahgu

In the edge case where a publication is a single component resource and it has a title, sure, a UA can function fine. And in that edge case, nothing prevents the authoring tool from adding that title to the manifest! Everyone's happy, and the user doesn't do any extra work.

My point in the original thread is that dealing with hard requirements goes well beyond just telling people they have to fulfil them in their files. If the requirements are essential then you need to define how a User Agent is supposed to make up for their absence if the UAs are to provide an acceptable user experience. You can't just tell authors to include the feature. That won't provide users with the feature they need to be able to function because many authors will ignore you and make files that don't fulfil the requirement.

If it is essential then you need to tell UAs that when the essential requirement can't be fulfilled in any way, then they must not try to display the publication, otherwise many of their users will be faced with a non-functional experience. For better or for worse, going down that route is pretty unpopular among web developers.

A "MUST" in a spec has to have consequences; that's what makes it a must and not a strongly recommended should. And those consequences make implementation for both authors and UA-vendors much more complicated in ways that are can be pretty subtle.

from wpub.

I made a comment on the original thread that relates to this. While it is not specific to title or metadata and is about the general design of the format, it is relevant to this issue. #15 (comment)

[...] As a principle, if you are going to make a hard 'MUST' requirement then you need to either explicitly mandate UA failure when the requirement isn't fulfilled or you need to specify some form of error recovery [...]

from wpub.

@lrosenthol An identifier is not the same thing as a title. If my content documents are entitled "copyright" "chapter one" and "appendix", that does not identify the document in a descriptive sense.

from wpub.

@TzviyaSiegman

@baldurbjarnason We can create consequences to MUSTs. We have not even drafted the MUSTs yet. Please help us author the consequences.

I'm not going to help author the consequences and fallbacks for a scenario I'm not convinced is valid. I still don't see why the title of the first primary resource in the reading order isn't a reasonable and evident fallback, given that there seems to be a consensus that a web publication must have at least one primary resource and a default reading order.

from wpub.

I still don't see why the title of the first primary resource in the reading order isn't a reasonable and evident fallback

@baldurbjarnason I'm not sure, but I think I detect a proposal.
Proposal: In the event that a WP does not have a title, the title of the WP shall default to the title of the first primary resource.

from wpub.

I am okay this mostly, but I'd argue that a conformant WP MUST have at least one resource with a title. A filename is not a title.

Although now we are getting back to Tzviya's question: are we talking about manifest or about WP, and about the earlier comments people made about whether there are some manifest requirements which don't always have to appear if there's an implicit fallback. In this case would it be

A WP manifest MUST have a title if no resources are present which have titles. In the event that a WP does not have a title, the title of the WP shall default to the title of the first primary resource.

from wpub.

@lrosenthol

As this conversation is about the manifest - all of my comments have been
about having a title as an MVP item for that.

I agree. My sense is that, based on the discussion above, there is a strong case to be made that titles are a hard MVP requirement for a web publication as a whole but not for the manifest. However, if the publication otherwise doesn't provide a title, then the manifest must provide it.

Echoing @deborahgu's comment above (#20 (comment)), this sounds reasonable:

A WP manifest MUST have a title if no resources are present which have titles. In the event that a WP manifest does not have a title, the title of the WP shall default to the title of the first primary resource.

So while it's a little bit more detailed than just "titles aren't a MUST in the manifest" it covers the use cases outlined so far and, for example, makes a single primary resource publication simpler to author without sacrificing accessibility.

from wpub.

Thanks to @rdeltour for reminding me to look at Web App Manifest, which has the concept of a name and short_name of the App (package). See https://www.w3.org/TR/appmanifest/#application's-name.

The application's name is derived from either the name member or short_name member (if either is present) - otherwise, it is generated by the user agent or provided by the end-user.

When either member is missing from the manifest, a user agent may use the name member as a fallback for the short_name member or vice versa.

If the name and short_name members are undefined, the user agent should assign a default name (e.g., "Untitled"). Alternatively, a user agent may allow the end-user to input some text that can serve as the application's name.

When both the name and short_name members are present, it is left up to implementations to decide which member is best suited for the space available (e.g., the short_name member might be better suited for the space available underneath an icon).

from wpub.

I don't have the luxury to dedicate another day to W3C work but I will quickly note that we do have an overall conclusion that impacts the overall design of the manifest based on comments such as #20 (comment) and #20 (comment).

Namely, even when we have features that are a definite must for a Web Publication as a whole it does not follow that the best solution is to require them to be a part of the manifest. We have a very limited ability to police and enforce the validity of manifests authored in the wild. If we depend on the willingness of authors to provide valid code, we end up with an ecosystem that's largely inaccessible and broken for many users. We should try to avoid repeating that mistake if possible. Whereas we can require that User Agents provide these features and we can back that requirement with guidelines for recovery or fallbacks to ensure consistent behaviour. Sometimes that will mean describing a simple fallback algorithm (as I've suggested above with "title"). Sometimes that requires active User Agent intervention (as per the Web App Manifest spec).

I'd like to suggest that unless we are absolutely convinced that a stated requirement cannot be fulfilled through other means, we avoid as much as possible to make any feature a MUST provide when it comes to the manifest. That way we can keep the manifest specification manageable.

from wpub.

from wpub.

from wpub.

@baldurbjarnason

If a title isn't essential and the UA can design an acceptable user experience where the property may or may not be present, then it really isn't a 'MUST'.

UA can't design an acceptable user experience for AT users in the absence of the property.

(This can said about any number of things we aren't labeling as MUST. Whether this means we're inappropriately second-classing AT users, or whether it means the rule as stated is imperfect, is not a question to resolve here.)

from wpub.

UA can't design an acceptable user experience for AT users in the absence of the property.

Are UAs incapable of designing an acceptable user experience in the absence of a publication title even when the primary resources have titles? Even when there is only one primary resource?

from wpub.

@deborahgu you wrote in a previous comment:

When authoring an EPUB Publication each EPUB Content Document also requires a descriptive title that describes its content. If not provided, Assistive Technologies often will announce the name of the file to users.

To me, this clearly addresses @baldurbjarnason 's point that UAs (and even ATs) can happily go about their business with missing titles...

from wpub.

Likewise, including a title for every Content Document is complementary to providing a title for the publication: the overall accessibility is affected if either is missing.

But why?!?!

Why does it effect overall accessibility to have individual titles for content documents but not for the overall publication? I assume I'm misunderstanding and that's not the question, because this goes without saying. You can't identify a publication by the names of its component sections.

from wpub.

@lrosenthol In fact, the opposite. Announcing the filename is not happily going about your business.

You've done accessibility work, so I assume you've tried to read a page where the images don;'t have alt text and the screen reader announces illustrations as "DJN10045nokia.jpg", right? Announcing filenames is actively disruptive and non-useful. There's no felicity there.

from wpub.

@baldurbjarnason

Are UAs incapable of designing an acceptable user experience in the absence of a publication title even when the primary resources have titles? Even when there is only one primary resource?

In the edge case where a publication is a single component resource and it has a title, sure, a UA can function fine. And in that edge case, nothing prevents the authoring tool from adding that title to the manifest! Everyone's happy, and the user doesn't do any extra work.

from wpub.

@BigBlueHat

you're going to have to explain "ad-hoc publication"

The simple answer is something that is written and distributed, usually with a limited audience (perhaps even an audience of 1). There is no formal process for their authorship or for their distribution. Consider the many Office or PDF documents that you probably receive in your email every day - they are all ad-hoc publications.

as I'm not sure why you'd insist that title not be required for a publication. The act of publishing is naming a collection of stuff.

The act of formally publishing something, yes. But if an Admin wrote up something for their boss and emailed it, they aren't going to bother with a title. Or consider a document that is being produced for the explicit purpose of machine processing - what purpose does the title serve?

If there is no title, what do you propose is displayed/heard/presented in a listing of publications?

Who said that there is such a thing as a "listing of publications"?

from wpub.

@deborahgu

Why does it effect overall accessibility to have individual titles for content documents but not for the overall publication?

I would phrase it a bit differently. If I have individual titles for each content document, why does the lack of one for the entire publication impact accessibility?

You can't identify a publication by the names of its component sections.

You identify a publication by its identifier - that's why we are spending the time to work on that section. And why I would agree that the identifier belongs in the manifest.

from wpub.

1. @deborahgu and @lrosenthol Are we arguing about whether a WP requires a title or whether a manifest requires a title? If this is not about manifest, please start a new issue.
2. @baldurbjarnason We can create consequences to MUSTs. We have not even drafted the MUSTs yet. Please help us author the consequences.

from wpub.

@lrosenthol

Who said that there is such a thing as a "listing of publications"?

The browser's "bookmarks" UX...among many others.

Also, there's nothing preventing the authoring tools from auto-generating a title--which is the current habit of Word, Atom feed publishers, and HTML editors the world over. It's going to put something into that field...even if it's just the current date, file name, or the first line of content from the document (ala email subject lines in many mail clients).

There's always likelihood of invalid, (bad) lazy scenarios...but we're not specing for those folks. 😁 This spec is for the content authoring and reading systems that want a gold ⭐️

from wpub.

@TzviyaSiegman

@baldurbjarnason I'm not sure, but I think I detect a proposal.

Proposal: In the event that a WP does not have a title, the title of the WP shall default to the title of the first primary resource.

That sounds like a sensible plan, even if saying so is a bit self-serving 😊

from wpub.

In the event that a WP does not have a title, the title of the WP shall default to the title of the first primary resource.

unless the first primary resource isn't HTML, in which case ?

from wpub.

@mattgarrish

unless the first primary resource isn't HTML, in which case ?

That thought just crossed my mind as well.

How about: In the event that a WP does not have a title, the title of the WP shall default to the title of the first primary resource in the default reading order that has a title. If titles are completely absent from the primary resources the title should default to the file name of the first primary resource.

from wpub.

from wpub.

the title of the WP shall default to the title of the first primary resource in the default reading order that has a title

Yes, this is generally what I was thinking. But maybe it's unrealistic to expect it should look past the first document, as we don't want to force it to peek into each document, and once you pass the first document who knows what the title might be specifying. Seeing the above comment, perhaps it could just be:

"A Web Publication MUST have a title. If the creator of the Web Publication does not specify a title in the metadata section, a user agent MUST use the title of the first primary resource. If the title of the first primary resource is not provided or cannot be determined from the format, the user agent MUST use the URL of the resource as the title."

It's hard to answer these kinds of specific questions at this stage, but I like that this gives flexibility. If we allow embedding of manifests, for example, all it would mean is grab the title of this HTML document. Redundancy gone.

from wpub.

@mattgarrish

I think that's a reasonable alternative approach if the feedback from potential implementers is that the other version is too onerous. But I don't think we should immediately jump to that conclusion.

Given that <title> is a requirement for HTML files (at least in a primary resource context) and an option for SVG, most of the time the likely presence of a title in any given primary resource can be inferred from the media type. So when given a graphic novel with 100 JPEGs as primary resources and one final HTML page as a copyright page, the UA won't have to scan all primary resources for a title.

from wpub.

But I don't think we should immediately jump to that conclusion.

Agree, that's why I find this discussion a bit rushed.

most of the time the likely presence of a title in any given primary resource can be inferred from the media type

Yes, but I'd expect the publication title to be in the first resource if it has a meaningful one. A title of "copyright", if that's all the UA can find, is arguably more useless than a URL, as you can generally get some useful information from a URL like the domain and path (even if the file name itself is generic or useless).

But I'm happy to let this rest for now. I just like that we're taking the time to consider more than what we want to mandate.

from wpub.

@mattgarrish

Agree, that's why I find this discussion a bit rushed.

Yes and no. You're right that if we were going to write that out into a draft spec right now, it'd definitely be rushed. From my perspective it's more about allaying people's concerns that an important issue won't be ignored even if it isn't addressed here, in this specific issue.

So, to get a consensus that title isn't a requirement of a manifest MVP it is essential for those who are certain it is a requirement for the publication to know that their concerns will be addressed. To settle this issue we need to be able to say with some certainty that we will be able to handle this, even if we don't have the exact specifics yet. We don't need to decide which specific tactic we'll use but we do need to have some certainty that they are viable. And I think we have that.

But I'm happy to let this rest for now. I just like that we're taking the time to consider more than what we want to mandate.

Yeah, I think we've discussed this enough to get a rough consensus on this particular issue (title as an requirement for a minimum manifest) and we can refer back to this discussion later on when we have to get into more specifics on how we can require a title for the publication as a whole.

from wpub.

Just an observation from a quick test. Browsers (seem to) consistently display the content of the (HTML) <title> in (some version of) a title bar. If the <title> is missing or empty, they seem to fallback to the URL (in at least one browser just the domain name, and when using file:// just the file's base name). This seems to also be the behavior for "plain" SVG. For other resources, the filename seems to be used, possibly with additional information (e.g., image dimensions are often included).

from wpub.

This issue is resolved with #51

from wpub.

See telco discussion on closure.

from wpub.