Repository navigation
Some DPUB roles are too generic (such as "part") #39
Description
Several of the roles are too generic. "part" for example.
From 9 March 2015:
https://lists.w3.org/Archives/Public/public-pfwg/2015Mar/0021.html
Several of the roles are too generic. "part" for example.
From 9 March 2015:
https://lists.w3.org/Archives/Public/public-pfwg/2015Mar/0021.html
Activity
joanmarie commentedon Apr 23, 2015
+1 to this being too generic. Reading the note in the current Editor's draft, it says "CHANGING THE TERM TO BOOKPART OR SIMILAR WOULD RESTRICT THE USAGE UNNECCESSARILY." Could you please provide an example where such a change would result in an undesirable restriction? Thanks!
mattgarrish commentedon Apr 23, 2015
Publishing isn't all about books, so calling things book* suggests use isn't valid for a part of a legal document or a part of a journal, etc. It's especially awkward when no other roles in the publishing vocabulary are similarly named, and we intend these to be as generic as possible. We'd prefer to find a name that isn't tied to a specific type of electronic document.
joanmarie commentedon Apr 23, 2015
Thanks for the clarification. I wonder if there's some sort of way to keep it as generic as possible while still limiting it to documents. "docpart" seems awkward, but "part" on its own seems problematic.
mattgarrish commentedon Apr 23, 2015
Well, docpart was my best offering as an alternative, too... but I also wondered if "doc" sufficiently differentiates it from a part of a web page.
I don't think anyone disagrees with this particular role being problematic as named, we just got stuck on a good alternative.
mattgarrish commentedon Apr 23, 2015
I'm now wondering if "thematicpart" might do, at least to avoid prepending a format.
It would fit for books, and probably for journals, but legal would be a bit of a stretch. I don't know that we can ever satisfy everyone and not be too generic, though, and we're not trying to solve all of publishing.
joanmarie commentedon Apr 24, 2015
I'm brainstorming (and not familiar with your industry, so forgive any silly questions)...
Is a "part" definitely going to be a fully contained element? In the example you currently have, the "part" role is associated with the body. But parts of books can of course have a significant number of chapters in them. Which makes me wonder if a part isn't so much a container, but a named separator, not entirely unlike your "pagebreak" role.
mattgarrish commentedon Apr 24, 2015
That's a hard question to answer, as it depends on what form the content comes in.
A part may start life as a full-fledged container, but by the time the content is generated as an ebook the part may end up a single heading alone in a file, effectively a kind of separator between chapters instead of a wrapper of them all (to avoid file size restrictions in reading systems and large file rendering problems).
Ideally it is a container, though, and is noted in the table of contents as part headings still contribute to the document hierarchy..
joanmarie commentedon Apr 24, 2015
So, aside from industry terminology, is your "part" the same as the core "region" role as described at https://rawgit.com/w3c/aria/master/aria/aria.html#region?
mattgarrish commentedon Apr 25, 2015
Yes, and I was going to say that's why we put the landmark superclass role on it, but obviously that's not the case right now.
Beyond the misplacement of "section" in the abstract field, it looks like when we changed many of the roles from section to landmark earlier on in the process, that one was missed, no doubt because of it being out of place as it was.
But there are other editors, so I'm not going to say that's definitively why it's not a landmark, only that I agree it is a kind of region.
joanmarie commentedon Apr 25, 2015
So here's what I'm thinking: Maybe you don't need a "part" role -- at least not one called "part" anyway. At least not yet. If publishers don't intend to use the core ARIA "region" role for anything else, and if as @richschwer suggested, roles are going to be added primarily by tools rather than humans, guidance for tool creators could be added to your spec. We could potentially add book (and other document) parts as an example of an appropriate use of "region" to the core spec. And then see who all screams, demanding a specific role called "part." If that demand happens, then we're no worse off than we are today wondering what to call it. ;)
Thoughts?
mattgarrish commentedon Apr 25, 2015
Actually, we floated that idea past the dpub group, and while they'd prefer a semantic, doing just that because of the inherent ambiguity wasn't seen as the end of the world, at least by those who voiced an opinion.
We didn't strip the role at this point because parts are so common in publishing we were hoping to find a solution that could retain the semantic. But, as was noted on the same call, there's also potential confusion between a part as a container of chapters and a part as a subsection of a glossary, bibliography or index, and we weren't looking to cover both those cases.
The same could be done for volumes, too, the next tier up in the publishing hierachy from parts (they're rare enough that we didn't include in this core proposal).
halindrome commentedon Apr 25, 2015
I guess it comes down to A11Y. Some books have parts. That's important.
The semantic associated with it is important for grouping of like concepts
Basic number theory; Part II - Numbers through history; Part III...). On
the other hand, it is absolutely an abstraction. As are MOST of the
concepts that are being introduced. Section == Chapter == Subsection.
Let's focus not on the NAME, but on what the container needs to convey to
the user. I would want the ability to navigate by Part in books that have
them. Within a Part, I want to navigate by chapter (probably). Having a
specific name that is exposed to the AT means it is possible to have those
sorts of groupings. If we don't have a specific name, then the AT can't
distinguish between a Part and any other "landmark" in the document.
So.... I am inclined to recommend that specific terms be available WHEN
THEY WOULD IMPROVE ACCESSIBILITY. I maintain that "part" would improve
A11Y.
On Sat, Apr 25, 2015 at 7:05 AM, Matt Garrish notifications@github.com
wrote:
Shane McCarron
halindrome@gmail.com
richschwer commentedon Apr 27, 2015
So, here is where we would get confusion if "part" was not preceded by a dpub-:
We are looking at SVG drawings from Boeing. It is possible that they would have a "part" in a drawing.
Part is incredibly abstract on its own and has different meanings in different contexts or taxonomies.
mattgarrish commentedon Apr 28, 2015
Can we drop part as an issue from the specification after today's call?
If either a vocabulary identification mechanism or hardcoded labels get adopted, this term becomes bound to the publishing module, so there no longer appears to be pending conflict.
cookiecrook commentedon Apr 28, 2015
I don't think we can drop this until the prefixing issue is resolved. Is that what you meant by "hardcoded labels"?
cookiecrook commentedon Apr 28, 2015
I'm also not convinced there is a need for this. Book "parts" are usually labeled by a heading such as "Part I", "Part II", etc. Are they not? If so, this seems like any other nested grouping container. It could probably just use the "region" role.
mattgarrish commentedon Apr 28, 2015
Right, avoiding calling them hyphenspaces, since no one has a good name and it's not yet clear if they will be mapped.
But whether "xyz-" is added or a vocab attribute identifies their vocabulary, doesn't that address the domain isolation aspect of the role being too vague for general use?
stevefaulkner commentedon Apr 29, 2015
On 28 April 2015 at 23:06, Matt Garrish notifications@github.com wrote:
+1 to 'xyz-' as I think it is much clearer when exposed to acc API's to
have the prefix in the role value.
Regards
SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
richschwer commentedon May 1, 2015
I create an issue to create a vehicle for modular extensions. This is issue 709. I will put it on the April 7 agenda.
TzviyaSiegman commentedon Jul 10, 2015
Thank you for your feedback. This issue has been resolved by editing the document to comply with the rules for extending ARIA (https://www.w3.org/WAI/PF/wiki/ARIAExtensions).
Clarify description for aria-keyshortcuts (#1713)
Clarify description for aria-keyshortcuts (#1713)
Clarify description for aria-keyshortcuts (#1713)
Merge pull request #39 from w3c/fix/issue-38
add change log entry for PR #39
Merge pull request #39 from w3c/update/split-ps