-
Notifications
You must be signed in to change notification settings - Fork 118
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
add sectionheader and sectionfooter roles #1931
base: main
Are you sure you want to change the base?
Conversation
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.
need to remove instances of referring to fieldset
that got copied over accidentally.
@scottaohara wrote:
Seems reasonable. Checking with others before confirming. |
@cookiecrook wrote:
No comments in 24h. AX API proposals okay as is. Thanks. |
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.
Bear with me as I work out my thoughts on this one because I'm not sure where I land -- whether to introduce these new roles or to leave the distinction between landmark header/footer and not-landmark header/footers in html-aam entirely.
Just to be clear, if this PR lands, the corresponding change in core-aam would be that https://w3c.github.io/html-aam/#el-header and https://w3c.github.io/html-aam/#el-footer point to these new roles and say use these mappings?
I guess one reason why we should introduce these roles is because it is a place to document the concept of a "section header" and "section footer" as apposed to the landmark header/banner and landmaker footer/contentinfo. This makes me feel like there should be some very author-specific guidance about this, and makes me realize we aren't tracking changes to MDN with changes in the spec. Should we be tracking MDN changes? Alternatively, it seems almost too basic, but should there be an APG example for this?
Also, where is the current author facing documentation that says a html header
and footer
are considered landmarks in these cases and not in these other cases? I just check mdn and it is not there.
Also, would we want a "screen reader guidance" section as well? Essentially explaining you can expose this information when you feel like it's necessary, as @cookiecrook mentioned in the VoiceOver case?
No AT changes are needed on Mac. This is only an engine change that results in a different role description. Nothing more. On the call today, @scottaohara mentioned the same was true on Windows. |
@spectranaut probably not a bad idea to add a check for has MDN documentation been updated - these docs are often behind the curve with a11y info/updates. header mentions the 'scoped' nature of the header element - lightly, now. footer calls out an old webkit bug in its accessibility section. |
@jnurthen @cookiecrook @spectranaut any other thoughts on this preventing it from merging? got reminded of it when reviewing the (now linked) WPT. re: author guidance on when a header/footer is a section header/footer vs the landmarks. that can be added to MDN, but that's blocked on this change being made. One could argue the info could be more overtly stated with the current reality of how these elements work. But I would rather make one change than two. |
I was suggesting the role name be changed from |
thanks @cookiecrook. for some reason i had a memory of already doing this, but clearly my memory was faulty. i've actually done it now. |
Per our new process, changes to the ARIA spec can't land until there are implementations or implementation commitments, and related changes to the AAMs/Accname, so I think you need to open all those PRs and bugs on browsers. But I just realized we sort of need an intermediary, because we shouldn't open bugs on browsers until we have "consensus" from the working group... we we need a way of keeping track of that some how. I think it used to be that once we had consensus we merged, and that is how we "kept track" of what had consensus. |
yes, there does seem to be something with this revised process that needs working out, as I didn't think it would make sense to file bugs until reviews were completed (and i did the work james requested and i flubbed on actually doing, until yesterday). also, as we've already had a few meetings (triage, then the meeting where i actually babbled on about the proposal - resulting in me doing the work, and THEN we did initial triage of the PR) isn't the fact there were reviewers assigned (and anyone else can also review now) the end point of the consensus process? E.g., once we have approving reviews, then that means there is consensus. If more consensus is needed after that, it seems like the process is overcomplicated, or we aren't doing consensus right. |
Ah good point, @scottaohara -- three reviews = consensus. So, we can open issues on implementations after there are three reviews, and we can merge after there is at least one implementation and implementation commitment |
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.
I think these sections look good! Very clear description.
Assigning to myself to make tests and issues on browsers. |
Sorry if I've missed something, but I'm a bit unclear: will this result in changing HTML |
@jcsteh no, these roles are in addition to those. To quote @scottaohara's starting comment:
|
Ah, I get it. I think I was (and am still a little) confused by the "if they are given properties important to accessibility (focusable, named)" condition. If we're creating new roles for these, why impose that condition only for implicit roles on HTML elements? As an example, a |
that's the problem that these new roles are trying to solve. right now header and footer, if not landmarks, are treated as generic. but in HTML header and footer have semantic meaning regardless of their usage. while these elements always have semantic meaning, we talked alot about how we don't to necessarily add new announcements of these roles for situations where the content alone is understandable. hence why we wanted to treat these similar to the group role - where if the group is unnamed or not focusable, then the group (and these roles) wouldn't have to be overtly announced to users. and then on the flip side, the other reason for these specific roles is because authors do provide header and footer elements accessible names, or make them focusable (for better or worse) but if these elements aren't scoped to be landmarks, then they are named/focusable generics and we want to avoid that. sometimes having these html elements be nameable and sometimes not. |
That's reasonable, but there's an important distinction between "not announced by screen readers" and "not exposing the roles to accessibility APIs". With the group role, it's always exposed; screen readers just choose not to report it if there's no significant property. If I read your description correctly (and maybe I'm misunderstanding it), you're suggesting that |
Adding new roles to .tenative file until implementation is complete See w3c/aria#1931
@jcsteh the intent of this was for these to be able to essentially be so |
Do they? HTML-AAM mostly maps them to "generic", with the exception of ATK. (IMO, UIA doesn't count because it basically overloads/abuses LocalizedControlType for everything instead of having proper native semantics. 😒)
For the sake of absolute clarity, "when not exposed as a banner" would be the only exposure condition as far as HTML-AAM and thus browsers are concerned? (I understand the intended screen reader behaviour here; I'm just trying to be sure I fully understand the intended API mappings.) |
Yes. The header and footer elements are meant to be used for more than just for
yes. Essentially header and footer would not be exposed as generics anymore. So the conditions for them to be exposed as banner/contentinfo, respectively remain the same, and the instances of where they would have instead be generic would instead map to these proposed new roles, again meaning to behave as 'group' roles with implicit aria-roledescriptions. |
Adding new roles to .tenative file until implementation is complete See w3c/aria#1931
…r role tests, a=testonly Automatic update from web-platform-tests ARIA: Add sectionheader and sectionfooter role tests (#46142) Adding new roles to .tenative file until implementation is complete See w3c/aria#1931 -- wpt-commits: 6618b73099d0aa8c9feed33a62f79d706dbb75f0 wpt-pr: 46142
…r role tests, a=testonly Automatic update from web-platform-tests ARIA: Add sectionheader and sectionfooter role tests (#46142) Adding new roles to .tenative file until implementation is complete See w3c/aria#1931 -- wpt-commits: 6618b73099d0aa8c9feed33a62f79d706dbb75f0 wpt-pr: 46142
…r role tests, a=testonly Automatic update from web-platform-tests ARIA: Add sectionheader and sectionfooter role tests (#46142) Adding new roles to .tenative file until implementation is complete See w3c/aria#1931 -- wpt-commits: 6618b73099d0aa8c9feed33a62f79d706dbb75f0 wpt-pr: 46142
adds proposed header and footer roles to allow authors to identify areas of the page that would fit the more general HTML definition for the elements of the same name (and would not be considered landmark elements). These would also allow for the respective HTML elements to expose these new roles - essentially 'renamed' group roles - if they are given properties important to accessibility (focusable, named) but are not meeting the conditions to be exposed as banner / contentinfo landmarks. The alternative is to just expose the elements as groups, which is doable, but arguably also overloads the use of the group role.
15b7d71
to
0a1df33
Compare
adds proposed header and footer roles to allow authors to identify areas of the page that would fit the more general HTML definition for the elements of the same name (and would not be considered landmark elements).
These would also allow for the respective HTML elements to expose these new roles - essentially 'renamed' group roles - if they are given properties important to accessibility (focusable, named) but are not meeting the conditions to be exposed as banner / contentinfo landmarks. The alternative is to just expose the elements as groups, which is doable, but arguably also overloads the use of the group role.
Closes #1915
Implementation tracking
Preview | Diff