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
Roles with required accessible names #1466
Comments
Accessible Name: Required, Not Required, Prohibited |
From today's WG meeting:
legend / label and "how" roles can be named (encapsulation etc.), as well as are there any other roles (in my original comment) that should/should not require a name – needs to be a new deep dive / topic of discussion. landmarks that 'should' be named, among other 'author shoulds' (re: |
@jnurthen @scottaohara |
@jongund No - that would be a normative change and would require re-entering CR. This is not a new thing in 1.2 (and has been this way for 6+ years) so it doesn't seem like we would need to fix in 1.2 |
@scottaohara |
When looking into issue #1421, it got me reviewing all the roles that can be named / require naming, and a few things stuck out: I have broken down the topics of conversation by heading 2, with heading 3 being proposed actions. My last topic, 'questions' has no actions at present. All actions are of course my opinion and open to further discussion if people disagree.
name true, false, n/a
In the characteristics table, "Accessible Name Required" is marked as "true", "false" and also not at all for some roles which can be named. I would expect that it be "true" for all instances of roles which require a name. False for all roles which can be named, but do not require a name. Roles which prohibit naming would not need this table row
action item
All roles which require names need to be marked as "Accessible name required: true". All roles which can be named but do not require a name either need to be consistently marked as "Accessible name required: false" or not have that row displayed.
landmarks SHOULD
For landmark roles only
form
andregion
require names, which makes sense because without them these roles won't generally be exposed. However, I think other landmark roles would benefit from a "authors SHOULD name..." for when there are multiple instances of landmarks in a document.action item
add an "authors SHOULD name..." sentence to landmark roles where more than one could exist in a document at a time.
roles which are missing name required
group
- won't be exposed otherwise, so needs it similarly torole=region
androle=form
tab
- like other interactive controls, needs a nameform
- is marked as required, but it isn't marked as such under the listing in 5.2.8.4 Roles Supporting Name from Author - apparently my PR Editorial: capitalize "true" #1465 fixes this (thanks for the heads up @carmacleod)separator
- if focusable, it would make sense to make sure it has a nameaction item
Mark these roles as naming required - or fix instances where they aren't referred to as such.
roles which should not require a name
tooltip
- a tooltip should be represented by its contents / almost never interacted with directly. so... not convinced it should have a required name.label
andlegend
- acaption
is prohibited from being named. these should be prohibited from being named too as they would perform similar functions.action item
Do not require names on these roles.
label
andlegend
should be changed to name prohibited to matchcaption
.questions
tree
andtreegrid
require a name, but other similar roles (of varying similarities mind you)menu
,menubar
,toolbar
,tablist
, andnavigation
do not. shouldtree
/treegrid
continue to require a name, or should some of these other roles require a name too?alertdialog
,dialog
,table
,grid
,tabpanel
need a quantifier to their required name status? e.g., if these roles contained a heading, or were preceded by one, would that not provide the necessary context? I think they all would benefit from having a name, but I'm a bit torn on that being a requirement, especially when host language equivalents do not have such requirements, which then leads to the author confusion as outlined in Questions about role=dialog vs <dialog> #1421.The text was updated successfully, but these errors were encountered: