-
Notifications
You must be signed in to change notification settings - Fork 125
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
Consider collapsing Base Concept category into Related Concepts #1679
Comments
Just as a quick ref for others when reviewing this issue, here are all the roles that use "base concept" when pointing to the related HTML element
|
Here's a few that use Related Concepts when maybe they should have used Base Concept?
Another interesting contradiction is that in the definition for Base Concept, it says:
And yet, the definition of checkbox actually has |
I think the separation into base and related concepts is not wrong, it should just be done and described correctly:
Currently it seems to be really wildly mixed up. Even the spelling is different: If this separation in reference to other specification and reference to ARIA specification is not desired, I am for abolishing base or related concept and having only one category |
I'm not sure whether restricting Related Concepts to the ARIA spec is useful? For example, listbox role lists HTML It's probably also useful to keep Related Concepts unrestricted because the ARIA attributes section uses Related Concepts as well. For example, aria-description lists I agree that the presentation is wildly mixed up. :) There's even "<input[type="radio"]> in [HTML]" vs " element max attribute in [HTML]". We should standardize on the presentation of HTML elements in these categories. I guess my key question for this issue is, "Is it useful to have 2 categories?" |
@carmacleod I don't understand why |
@JAWS-test Hmm, I guess it would be ok to have Maybe I am being too picky. :) I am focusing on the "identical", and other folks are focusing on the "almost". For example, I think that |
What is accessibility other than a big fuzzy sweater with the words “it depends” embroidered on it? |
I want one! 😂 |
I wouldn't mind if the two categories were named and described differently, but I think the split I described would make sense, at least more sense than it does now. Base conceptARIA recently tries to establish parity with HTML. That's why I think it would be good to mention the corresponding HTML element for each ARIA role, because sometimes they don't have the same name. I don't care how close they are. It should be clear to everyone that an HTML element by itself brings a lot of great things (keyboard focusable, keyboard operable, appearance, states, change states on operation, etc.) - which is never true for ARIA elements. Here this must always be programmed by ARIA attributes (aria-checked for checkbox), HTML attributes (tabindex=0), Javascript (change the state) and CSS to it. If there are SVG elements or elements from other languages, they should be mentioned as well. The definition of "Base Concept" can be adjusted to make it clear that the HTML elements and ARIA roles are not identical and do not behave the same. Related conceptFurthermore, I think it would be good to name related ARIA roles, so that it becomes clear which role I can possibly use alternatively, because it might fit better or is easier to implement. |
Good point. I'm still not sure about restricting Related Concepts to only aria, but it always makes sense to include alternative aria roles. This issue will be discussed in an upcoming ARIA Working Group call. |
Following up from #1678 (comment), I am wondering whether having both Base Concept and Related Concepts is really all that useful? Perhaps it would be sufficient to just keep Related Concepts? If there's an existing Base Concept, it could simply be the first item in the list of Related Concepts? Thoughts?
The only roles that currently have both are button and option.
The text was updated successfully, but these errors were encountered: