@partdigital I really like that solution. Let me know if you need me to help with testing or anything else!
That could work but out of curiosity – how would a "use" operation differ from an "edit" operation?
If I don't apply the access policy to queries, then the taxonomy overview page does allow users to see all terms while only being able to manage terms that they are assigned to. The tradeoff is that since this also applies to entity reference fields, there isn't any such distinction at this level and I can assign any term regardless (which is a valid use case for many). I guess that could be addressed by our own field widget.
So I have three potential solutions:
- Custom field widget to address the above limitations
- Or split query settings to manage taxonomy overview page and entity reference fields separately
- Or continue down the path of creating a new "use" operation
Curious to hear your thoughts!
Thanks for the quick reply! I am using that access rule and it works, but I didn't realize that we had to use the autocomplete widget to be able to access those terms. I was primarily testing with the checkboxes/radio field widget. Makes sense now.
Our use case would be for a university structure that has departments and sub-departments. We have users who will be managing taxonomy at the sub-department level but not necessarily at the department level, so with this workflow they wouldn't be able to manage terms if they can't access the parent. I think that might be a fairly common use case and not a huge deal if parent terms are shown, but with a 403 or something on edit (which is what happens currently).
I would also expect that most users who are managing taxonomy with hierarchy are using the checkboxes/radios or other field widget. Can we support either a flattened structure or showing disabled parent terms with these widgets? If not, the next action here might be to update the documentation to make it clear that using terms with depth is only supported by the select widget.
Thanks again for a great module with great documentation!
nilubol → created an issue.
Added @April to the ping list.
Just submitted a patch with d10 fixes. There was one instance that the automated patch missed so the MR is more up to date than the patch.
volkswagenchick → credited nilubol → .
I haven't seen many recent resources out there on native browser datepicker accessibility, but a brief test using VoiceOver on Safari is proving inaccessible (the actual calendar itself is not accessible and the individual stepper labels aren't communicated, nor is the entire value when a value is changed). Chrome is marginally better, but still not the best experience when compared to other options out there. This was just a quick test using the two examples at https://pauljadam.com/guides/datepickers.html
I've been looking at alternatives for another project. So far this seems to be the most up to date list of accessible datepickers: https://www.digitala11y.com/accessible-date-pickers-roundup/
I tested keeping everything as-is and just adding aria-describedby to the password suggestion container, which does then expose this to screen readers. But, as mentioned, the placement and frequency with which this container updates isn't ideal.
If we keep the password suggestions where it is now (after the password fields), a user won't encounter this field until after they have already entered their passwords, rendering it useless or cumbersome to have to navigate back to update passwords. And as already mentioned by @rkoller, this can be missed by both sighted users as well as screen reader users.
If we move the password suggestions to above the password fields and leave it dynamic, the user will need to navigate past the (empty) suggestions box in order to get to the password fields. And because the list expands/contracts as you type in the password field, having this happen above the field you are typing in would be jarring to sighted users.
It seems that number four in @rkoller's list of suggestions makes the most sense here. A static, front-loaded passwords suggestion list reduces complexities and means that the user won't have to run through the password strength and list of requirements every time they type in the password field. Right now this content is being rendered in JS via user.theme.js so making this list static may also allow us to move this content into markup.
Additional usability review would be nice here. Sadly I just missed their office hours but adding the tag for visibility.
Tagging with WCAG SC 3.3.2: Labels or Instructions