-
Notifications
You must be signed in to change notification settings - Fork 26
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
readonly/disabled and form-associated custom elements #257
Comments
(For disabled it would make sense to use the https://html.spec.whatwg.org/#concept-fe-disabled concept instead as that's what you'd use on a given element to determine whether it's disabled, not the |
The thing about disabled appears to be a bug in html-aam for built-in form controls. |
On one hand, these should be exposed because they have semantic value and we expose them for native controls. This is the direction I'm personally leaning in. On the other hand, IIUC, there is no default styling for these states visually - the author has to style them - so it could be argued that the author should also be responsible for exposing the correct accessibility semantics (equivalent UX). |
If we want to go down that route, HTML would need to expose disabled and disabled for form-associated custom elements differently. But note that while they might not have a default style, they do match |
I don't quite follow your meaning here. Can you clarify how it would need to be exposed differently and why? |
Because html-aam would need to map one of them and not the other. |
Oh, you mean if we chose to not expose this for CustomElements. Note that I personally tend to think we should expose it for CustomElements. I was just presenting the other side of the argument as well for balance. |
@annevk and @jcsteh agree here, form associated custom elements should be able to expose these states, and any other applicable state that a native form control could. In general I would expect if a custom element is set to a specific role via its ElementInternals, then any allowed states and properties of that role should also then be allowed/exposed for that custom element. We can either go through each attribute and indicate that, for instance, the Glad to do whichever is more preferable, but I personally think the global statement/guidance would be easier to maintain, as the argument could be made that every custom element that has a defined role should then be listed for every attribute that role should allow for. e.g. the |
Yeah, we have it for |
@annevk well i think that's sort of related to what i'm asking here. File an issue for that attribute specifically, or note that really any/all attributes should mention they are associated with autonomous custom element or form associated custom elements if either of those have a role that exposes them as a native HTML element that supports said attribute. |
One important thing to note is that
As such tentatively I would recommend that the browser make all disabled FACEs count as disabled for a11y purposes, but that it not do so for readonly FACEs. Instead, authors need to implement readonly a11y semantics as part of implementing readonly user interactions generally. This would best be done via This seems more likely to lead to aligning a11y semantics with general UX, which IMO is probably a more important goal than aligning a11y semantics with default styles. I'm open to being persuaded otherwise, however. E.g. I could see the argument that authors are too likely to forget to set |
I suspect |
This was exactly what I was going to say. I think the more accessibility can be built-in and provided by default, the better. I can't think of a case where you'd want a FACE be The only risk I see is web developers marking a FACE as |
The case I'm imagining is component developers not implementing readonlyness at all, i.e. the control still being editable. That is, the page author has set The question in this thread is about how much the browser should do in reaction to the page author setting In other words, I think we're balancing two potential harms:
|
Another consideration: There are controls (such as a custom toggle switch or button) where the component developer intentionally would ignore the page author setting We could add some sort of opt-in as discussed in whatwg/html#5016 (comment) to help with this, but see that thread for some of the blockers there. |
Thanks, @domenic. As it often the case, things are more complicated. If there's an opt-in for the I'm also curious how ATs react to |
NVDA ignores it on all roles except textbox and checkbox. I'm actually not sure why this applies to checkbox. Note that this isn't web specific code - it applies to those roles in native apps as well - so it was probably done for some desktop use case rather than web. |
I wonder if when these are used on custom elements the accessibility state that exists for them ought to apply. E.g., https://w3c.github.io/html-aam/#att-readonly.
Related to whatwg/html#5016 (comment).
cc @tkent-google @domenic @johndai1984 @zcorpan @muan
The text was updated successfully, but these errors were encountered: