Use NameFrom: prohibited on more roles

[aleventhal]

In most cases it makes no sense to allow an author name for DPUB roles, and in fact could lead to confusion.
Name From = "prohibited" is new in ARIA 1.2. We should go through the roles and determine which should not have a label.
Probably most of the ones that are currently "author" should be prohibited. It doesn't make sense to have a named bibliography entry, table of contents, etc. In publishing or word processing, any relevant text is generally visible on the page.

Examples of core ARIA roles where naming is prohibited: https://w3c.github.io/aria/#namefromprohibited

[mattgarrish]

Isn't prohibited for cases where a name really can't apply?

I expect you're right that things like cover and biblioentry really don't have names, but wouldn't we want to keep any titled section as allowing a name from author?

[aleventhal]

Isn't prohibited for cases where a name really can't apply?

Ys

I expect you're right that things like cover and biblioentry really don't have names, but wouldn't we want to keep any titled section as allowing a name from author?

We can start by adding prohibited to the obvious ones, but I suspect that we don't really want to have a name from author in most of these roles. A name from author could often take the place of a hidden name e.g. via aria-label. Do we agree that the hidden names don't make any sense? As for a titled section, are you saying the section is aria-labelledby from the title? This is generally handled in HTML by just using heading structure. Adding aria-labelledby relations would be unexpected.

[mattgarrish]

Do we agree that the hidden names don't make any sense?

Publishers aren't as sensible as you might expect! There are many cases where sections omit headings. It's not uncommon for chapters to begin without a heading, just as one example (new page with only a blank space before the text begins).

You may also get multiple versions of things. You could have a condensed and full table of contents, multiple types of indexes, etc. If we take away author naming, then we exclude even the possibility of using aria-labelledby to distinguish these, no?

Granted, I could be out of the loop on where you're looking to go with naming of things. I know aria-labelledby isn't strictly necessary when there is a visible heading, but don't we make problems for backwards compatibility if we make the use prohibited? We can't tell publishers to just ignore any warnings/errors if that's what will result, as vendors often reject publications with any reported issues.

[aleventhal]

I just think that in publishing, it's probably a sign of an error of some of the content only shows up in a screen reader -- a sighted user can't read it, and it won't come out in embossed Braille output either. An error might help the publisher realize they are doing something wrong, in a useful way.

But, I agree with you that I may not be considering some things.

I wonder if it makes sense to allow aria-labelledby but not aria-label.

But perhaps we can defer this because it is not high impact, and we don't need to hold up DPUB-ARIA 1.1.

[carmacleod]

Should probably continue to allow naming of the 19 landmark roles, particularly where there can be multiple landmarks of the same type.

Of course, if a landmark has a heading, then aria-labelledby would be preferred.
Unfortunately landmarks are not automatically labelled by a heading, so the association has to be programmatically made.

DPUB landmark roles are:

• doc-acknowledgments
• doc-afterword
• doc-appendix
• doc-bibliography
• doc-chapter
• doc-conclusion
• doc-credits
• doc-endnotes
• doc-epilogue
• doc-errata
• doc-foreword
• doc-glossary
• doc-index (navigation)
• doc-introduction
• doc-pagelist (navigation)
• doc-part
• doc-preface
• doc-prologue
• doc-toc (navigation)

[jnurthen]

Need to update ariaChild in aria-common to support this

[pkra]

Can this be closed? #28 resolved the two most problematic cases. doc-pagebreak seems to be the only odd case (being more permissive than its superclass); see also #30 (comment) and #50.