New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prohibit label on certain roles #985
Conversation
|
I considered this but thought it might be worth calling it out explicitly. I'm certainly willing to go either way on it, but I was also thinking of adding a corresponding type in the section https://pr-preview.s3.amazonaws.com/w3c/aria/pull/985.html#namecalculation corresponding with whatever we decide we would call the N/A value. |
Right. Hard to say. On the one hand, "Prohibited States and Properties: aria-label, aria-labelledby" is pretty explicit and right above where "Name from:" would be, but on the other hand I know what you mean - it is probably worth doing as much as possible to point out this particular change.
Right. If we do that, then we need to keep Name From. |
@stevefaulkner very interested in your feedback on this |
@jnurthen from looking at the changes it is unclear to me which roles are effected, is there a list of roles or a rendered view of the branch I can look at? |
@stevefaulkner
It's mostly new roles (except presentation) that we recently added for HTML role parity, so fairly minimal impact at the moment. This is paving the way for adding the "generic" role, which is intended to be the default role for div and span (and some others). Our current thinking is that generics should be nameless. Here's the PR Preview. If you look for the word "prohibit" in the preview, then you will hit all of the salient changes. |
index.html
Outdated
@@ -12325,10 +12439,11 @@ <h3>States and Properties</h3> | |||
</ul> | |||
</li> | |||
</ul> | |||
<p>If the author specfies a WAI-ARIA property on a role where that property is prohibited, the user agent SHOULD treat the property as if it were allowed. </p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we could put an editor's note after this statement to further discourage authors from ignoring the prohibition? Candidate text:
Note: At the present time, user agents have no obligation to ignore prohibited states and properties. However, this may change in a future version of ARIA in order to ensure interoperability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We agreed at the meeting to remove the text from the author errors section I believe. Could this go after line 498 instead?
I will need to split this into 2 (aria-common and aria) - leaving as one until ready for convenience |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Attributes, States, Properties
@jnurthen wondering about the reasons for choosing paragraph/note/blockquote. is there related discussion? |
@stevefaulkner there is some discussion in #833 - although note looks like a mistake - thanks for catching it. I am removing that - it was intended to be on none - but that doesn't follow the normal role structure. |
shouldn't
<span role="term" id="t">Word</span>
<span role="definition" aria-labelledby="t">
words to define word.
</span> |
When something has a valid name, screen readers might present that name and NOT present the associated text. So if there's no TL;DR: Should we prohibit naming of |
We would have to change
|
@joanmarie I had originally had that thought about For example, a definition that consists of two paragraphs: <span role="term" id="f">
Funny
</span>
<div role="definition" aria-labelledby="f">
<p>Causing laughter or amusement.</p>
<p>Making or given to making amusing jokes or witticisms.</p>
</div> |
It will be interesting to see how screen readers present |
Of the list provided the only definitely questionable one is I am on the fence about |
@stevefaulkner wrote:
I agree that it is feasible for screen readers to support named blockquotes. Most screen readers present the boundaries of blockquotes in reading mode, which provides a reasonable way of supporting names without confusing users. While it doesn't seem like a practice to recommend, prohibiting it may be unnecessary. However, I strongly believe prohibiting named paragraphs is necessary. |
w3c/accname#53 shows how accname could change to enable this |
I think this PR is good to go. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Nice work! Let's ship it!
commented "I think this PR is good to go."
I think this is ready to go. @joanmarie do you want to merge or should I? |
You did all the work. :) Go for it! Do please update the wiki so we can add it to the list of things which will need tests. |
Prohibits Labeling of the following roles: caption, code, deletion, emphasis, insertion, paragraph, presentation, strong, subscript, superscript
Preview | Diff