Consider collapsing Base Concept category into Related Concepts

[carmacleod]

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.

[scottaohara]

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

• associationlist
• associationlistitemkey
• associationlistitemvalue
• button
• cell
• columnheader
• form
• grid
• gridcell
• list
• listitem
• option
• row
• rowgroup
• rowheader
• searchbox
• table

[carmacleod]

Here's a few that use Related Concepts when maybe they should have used Base Concept?
(proving that nobody really notices the difference between these 2 categories, so probably just having the one for Related would be ok... and simpler):

• article
• blockquote (although it is missing the cite attribute, so probably Related is ok)
• caption (caption and figcaption)
• code
• em
• figure
• generic ? (div and span... and maybe a bunch of other elements?)
• heading
• mark
• navigation
• paragraph
• strong
• subscript
• superscript

Another interesting contradiction is that in the definition for Base Concept, it says:

For example, the checkbox defined in this document has similar functionality and anticipated behavior to a <input type="checkbox"> defined in [HTML]. Therefore, a checkbox has an [HTML] checkbox as a baseConcept.

And yet, the definition of checkbox actually has input type="checkbox" listed under Related Concepts.

[JAWS-test]

I think the separation into base and related concepts is not wrong, it should just be done and described correctly:

• base concept: similar element in another specification like e.g. HTML, SVG etc..
• related concept: related role in the ARIA specification (like listitem and option, link and button).

Currently it seems to be really wildly mixed up. Even the spelling is different: <option> in [HTML] vs. HTML div, HTML span

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

[carmacleod]

I'm not sure whether restricting Related Concepts to the ARIA spec is useful? For example, listbox role lists HTML <select> under Related Concepts. I don't think that belongs under Base Concept, but I do think it's useful to have it in Related Concepts.

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 title attribute in [HTML] under Related Concepts, aria-keyshortcuts lists Keyboard shortcut under Related Concepts, and aria-activedescendant lists SVG [SVG2] and DOM [DOM] active.

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?"
If not, then we should simplify by rolling everything into 1 category.

[JAWS-test]

@carmacleod I don't understand why <select> (or better: select size >1) should not be the base concept for listbox? The same applies for all the other examples you mentioned. I think a separation between ARIA and other specifications would be easiest and most logical

[carmacleod]

@JAWS-test Hmm, I guess it would be ok to have select size>1 as the Base Concept for listbox. Definitely not "almost identical" if just <select> without attributes mentioned.

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 <form> shouldn't be a base concept for role="form" because a <div role="form"> is really different from a <form>, however @scottaohara says "I could see an argument for either". So if we keep both categories, maybe I need to make more allowances for "fuzzy" base concepts. :)

[scottaohara]

What is accessibility other than a big fuzzy sweater with the words “it depends” embroidered on it?

[carmacleod]

I want one! 😂
@stevefaulkner ^

[JAWS-test]

@carmacleod

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 concept

ARIA 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 concept

Furthermore, 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.

[carmacleod]

sometimes they don't have the same name

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.