-
Notifications
You must be signed in to change notification settings - Fork 49
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
Addition: expand role allowances for fieldset element #442
base: gh-pages
Are you sure you want to change the base?
Conversation
closes #400 Updates allowances for the toolbar, menubar, menu, listbox, tablist, article, dialog and region roles to be used on the fieldset element.
I like the role expansion. I think some of these other roles might also merit being allowed on fieldset:
|
@scottaohara @smhigley Am not understanding the use cases for making control grouping/labelling semantic elements into non control grouping. |
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.
Until a discussion around addition of article
has occurred please do not commit
@stevefaulkner happy to talk about this when i get back to work in the new year. but quickly, the intent here is to stop disallowing the use of roles on elements where it's actually preventing the ability for some developers to rectify poor markup. An alternate proposal i have also been working on is to more clearly indicate what roles MUST NOT be used by developers, vs those which belong more in the SHOULD NOT category (e.g., use the appropriate HTML element instead). |
Yeah no worries let’s discuss when you are back!
…On Wednesday, 28 December 2022, scottaohara ***@***.***> wrote:
@stevefaulkner <https://github.com/stevefaulkner> happy to talk about
this when i get back to work in the new year. but quickly, the intent here
is to stop disallowing the use of roles on elements where it's actually
preventing the ability for some developers to rectify poor markup.
An alternate proposal i have also been working on is to more clearly
indicate what roles MUST NOT be used by developers, vs those which belong
more in the SHOULD NOT category (e.g., use the appropriate HTML element
instead). article, and maybe some of the roles that Sarah mentioned,
could very well belong to the 'should not' category... more on that when we
speak though.
—
Reply to this email directly, view it on GitHub
<#442 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGMCE3LKX623LM6STN5YNTWPRWYDANCNFSM6AAAAAATF3OCDM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
--
Regards
Steve Faulkner
Web Standards messaging
one t-shirt at a time
https://www.etsy.com/uk/shop/HTMLZ
|
noting that steve and i talked this over. going to move forward with the further clarification proposal i had mentioned in my last comment, so this PR will be adjusted. |
incorporates feedback from steve and sarah. includes language "the following roles are allowed, but are NOT RECOMMENDED" to introduce new allowed roles which _can_ work depending on what's been built, but there are probably better ways to do this. This wording is also used in #446, and allows for us to indicate these changes per element, without having to restructure the entire table (as this can be the end goal, rather than trying to get all allowed roles for all elements updated at once).
closes #400
Updates allowances for the toolbar, menubar, menu, listbox, tablist, article, dialog and region roles to be used on the fieldset element.
Preview | Diff