Through work and discussions with larger community, including several accessibility experts, there is a rather interesting open issue that we should tackle which is not currently addressed. Effectively, as we illustrated in our research, it can be very difficult to pin down a single definition of many of these components and in some cases there are open questions. A particular aspect that deserves our attention is a concern about "when is ARIA appropriate". ARIA was developed when we were very focused on Rich Internet Applications which meant something pretty particular. However, over the years the line between the "regular" web and the sorts of things we were thinking with "Rich Internet Applications" has blurred and co-evolved. Lots of times we see an implementation of, say a tabset, attempting to employ ARIA and they do it incorrectly, so someone points out that that is incorrect - because it is easily measured. What isn't as easily measured perhaps is whether it should be trying to do that at all and whether it helps or hurts or is harmless. There is a worry that perhaps it is unhelpful to user when it is part of a document or casual website as opposed to an "application" which one is intended to use often, gain familiarity with and seek efficiencies. In documents, people might prefer to navigate by headings or find it more intuitive to not have to use special keyboarding to access, as opposed to using more familiar interactions like the tab key and activating a link. There is even a strong probability that preference and intuition is very split on this.
Currently, the custom element in this repo only handles the application case which should use ARIA, but many many of the patterns and needs that it is best at solving for are precisely those that cause some to worry. For example, in the Rich Interet Applications cases, things like progressive enhancement or search-ability are often (unfortunately, perhaps) irrelevant.
As such, we need discussion and a resolution/advice before we can have something we can feel really good about recommending.
As I see it we have a few options:
We make a proposal at only works for one of the two cases
We add "web-like" versions to this element internally and default to using those (that means we have to define what we're missing) and add a simple flag, perhaps a boolean 'application' which can enable the ARIA forms.
I would dramatically prefer the second one for several reasons - not the least of which is that it centralizes a lot of complexity and simplifies things into a choice we can hope to explain which is binary - yes, or no... And the cost of remediation if you chose wrong is just "add or remove the attribute". Additionally, in the case that research shows that preferences really do vary, it leaves the UA open in a position where uses could express which they prefer and requires no additional author code to make that work. That might be ideal.
In any case, I am adding this as it seems like the most fundamental issue we have at this point and we need something we can link to as we move it forward.
Through work and discussions with larger community, including several accessibility experts, there is a rather interesting open issue that we should tackle which is not currently addressed. Effectively, as we illustrated in our research, it can be very difficult to pin down a single definition of many of these components and in some cases there are open questions. A particular aspect that deserves our attention is a concern about "when is ARIA appropriate". ARIA was developed when we were very focused on Rich Internet Applications which meant something pretty particular. However, over the years the line between the "regular" web and the sorts of things we were thinking with "Rich Internet Applications" has blurred and co-evolved. Lots of times we see an implementation of, say a tabset, attempting to employ ARIA and they do it incorrectly, so someone points out that that is incorrect - because it is easily measured. What isn't as easily measured perhaps is whether it should be trying to do that at all and whether it helps or hurts or is harmless. There is a worry that perhaps it is unhelpful to user when it is part of a document or casual website as opposed to an "application" which one is intended to use often, gain familiarity with and seek efficiencies. In documents, people might prefer to navigate by headings or find it more intuitive to not have to use special keyboarding to access, as opposed to using more familiar interactions like the tab key and activating a link. There is even a strong probability that preference and intuition is very split on this.
Currently, the custom element in this repo only handles the application case which should use ARIA, but many many of the patterns and needs that it is best at solving for are precisely those that cause some to worry. For example, in the Rich Interet Applications cases, things like progressive enhancement or search-ability are often (unfortunately, perhaps) irrelevant.
As such, we need discussion and a resolution/advice before we can have something we can feel really good about recommending.
As I see it we have a few options:
We make a proposal at only works for one of the two cases
We add "web-like" versions to this element internally and default to using those (that means we have to define what we're missing) and add a simple flag, perhaps a boolean 'application' which can enable the ARIA forms.
I would dramatically prefer the second one for several reasons - not the least of which is that it centralizes a lot of complexity and simplifies things into a choice we can hope to explain which is binary - yes, or no... And the cost of remediation if you chose wrong is just "add or remove the attribute". Additionally, in the case that research shows that preferences really do vary, it leaves the UA open in a position where uses could express which they prefer and requires no additional author code to make that work. That might be ideal.
In any case, I am adding this as it seems like the most fundamental issue we have at this point and we need something we can link to as we move it forward.