manifest: title #20
Comments
|
[Moved from 15]
for those of you who believe a title is mandatory - why?
What purpose will it serve? Is it for the user or for some processor (eg.
UA)? How do you see it being used?
…On Mon, Aug 7, 2017 at 1:35 PM, Tzviya ***@***.***> wrote:
on 2017-08-07 call, there was discussion about minimum manifest, based on
#15 <#15>. Is title required for the
minimum manifest?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#20>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AE1vNbHcmqBq4fPbI7iNyvlcOnbCs79xks5sV0rugaJpZM4Ovuuj>
.
|
|
@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:
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:
|
|
On Mon, Aug 7, 2017 at 2:28 PM, Deborah Kaplan ***@***.***> wrote:
@dauwhe <https://github.com/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"
In the context of formal publication, sure, I understand.
But not in the context of ad-hoc publication.
WCAG 2.4.2
<https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-title.html>
is addressing individual web pages, not publications. However, the SC is no
less vital from the standpoint of a coherent publication.
Again, I disagree. On individual content pages, I fully understand the
accessibility needs...but not as an element of the manifest.
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.
But the user never access the manifest! It is strictly (at least in my
and others minds) something that is purely machine consumable to aid the
UA. A user will never see/consume it directly - they will get the content
(which we agree has titles that are then exposed to AT)
(http://www.idpf.org/epub/a11y/techniques/techniques.html#sec-wcag-titles
),
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.
Right! Again, EPUB also puts the emphasis on the content document (aka
web page) - that we agree is where the title belongs. And even defines a
valid fallback for when that isn't present.
EPUB Accessibility <http://www.idpf.org/epub/a11y/> actually uses *title*
in its example of how accessibility needs to apply to a publication as a
whole, not merely the component documents:
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?!?! It is something related to how EPUB RS's might interact with
the manifest in an EPUB. If so, then I would say (as I did in an earlier
message in the other thread) that having title required for EPUB would make
sense.
But still unclear why it needs to be in WP...
|
|
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)
|
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.) |
|
@lrosenthol you're going to have to explain "ad-hoc publication" as I'm not sure why you'd insist that If there is no title, what do you propose is displayed/heard/presented in a listing of publications? |
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? |
|
@deborahgu you wrote in a previous comment:
To me, this clearly addresses @baldurbjarnason 's point that UAs (and even ATs) can happily go about their business with missing titles... |
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. |
|
@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. |
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. |
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.
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?
Who said that there is such a thing as a "listing of publications"? |
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 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. |
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. |
|
@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. |
|
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 ⭐️ |
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. |
@baldurbjarnason I'm not sure, but I think I detect a proposal. |
That sounds like a sensible plan, even if saying so is a bit self-serving 😊 |
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. |
|
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
|
|
As this conversation is about the manifest - all of my comments have been
about having a title as an MVP item for that.
…On Mon, Aug 7, 2017 at 4:15 PM, Deborah Kaplan ***@***.***> wrote:
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#20 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AE1vNTMA2UzreexCQPMyQ7nX1NkHWX_1ks5sV3BRgaJpZM4Ovuuj>
.
|
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:
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. |
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. |
|
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. |
Agree, that's why I find this discussion a bit rushed.
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. |
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.
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. |
|
Just an observation from a quick test. Browsers (seem to) consistently display the content of the (HTML) |
|
Thanks to @rdeltour for reminding me to look at Web App Manifest, which has the concept of a
|
|
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. |
iherman
modified the milestones:
Abstract Manifest,
Manifest Serialization/Concrete Manifest
|
This issue is resolved with #51 |
|
See telco discussion on closure. |
on 2017-08-07 call, there was discussion about minimum manifest, based on #15. Is title required for the minimum manifest?
The text was updated successfully, but these errors were encountered: