Accessibility improvements on multiple components #12028
Replies: 3 comments 12 replies
-
|
Hey, thanks for getting in touch! We'd like PRs for these. I have a few questions:
Should this read out "required" instead? Not all of our fields are HTML input elements, so the browser behaviour won't apply everywhere
This should be the user's name
Is that a problem? The tab order means that the menu is after the page content, so is it not convinient to tab through the navigation items once you've finished the content anyway?
cc @zepfietje for this one |
Beta Was this translation helpful? Give feedback.
-
|
Hi, Thanks for getting back to me, some of the things are considered more best practices instead of actual requirements. But if you're open to it I'm happy to help out. What would be the recommended approach for this, separated PR's for each or group them together in a single PR? As far as your questions go:
There are multiple approaches possible to resolve the issue, the basics are by using
Yes this can be easily added like this
Best practices, or what most people expect based on the most websites is to provide the menu options directly at the start and provide a skip link from there. A great article with details about this is: https://www.a11y-collective.com/blog/skip-to-main-content/
Haven't looked at the source code yet but I could image we can use the alpine focus plugin for this: https://alpinejs.dev/plugins/focus#x-trap |
Beta Was this translation helpful? Give feedback.
-
|
Separate PRs is good if they touch different areas of the system, but if you think that is too time consuming you can bundle them as long as you understand the review process will take longer |
Beta Was this translation helpful? Give feedback.
-
|
Might go for different PR's for the moment unless the area's are basically the same. Happy to see improvements on this regard are welcomed. I'll start working on some of them in the near future, first will familiarize myself with the code base |
Beta Was this translation helpful? Give feedback.
-
I'm aware of this, as most components' focus styling is similar to their hover style. What do you think, @danharrin @mikeslinkman? |
Beta Was this translation helpful? Give feedback.
-
|
For us it would be fine to handle this in version 4 if this prevents introducing breaking changes. For the moment I think we can list it in our accessibility statement as something that is being worked on. |
Beta Was this translation helpful? Give feedback.
-
|
You can also always add custom styling to your application to handle this in v3 already. |
Beta Was this translation helpful? Give feedback.
-
|
Yes we are also considering this so it might be an overlap between those to. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @zepfietje / @danharrin Yesterday I started working on the next improvement, focus trap for the drop-down. And I was wondering something about the desired implementation. Although it is recommended to have focus trap enabled in terms of A11Y, I can imagine some people might want to opt out of it. So what do you think about the following:
How do you guys feel about this? |
Beta Was this translation helpful? Give feedback.
-
Normally speaking (and verified) in the current version of filament we can do this by using one of two methods:
|
Beta Was this translation helpful? Give feedback.
-
|
Could you provide some links to best practices regarding focus trapping inside dropdowns? |
Beta Was this translation helpful? Give feedback.
-
|
Ofcourse, see the relevant links shared below: |
Beta Was this translation helpful? Give feedback.
-
|
Not sure if I misread, but neither of those documents mention focus trapping inside dropdowns? |
Beta Was this translation helpful? Give feedback.
-
|
You are right, we misread about that so for now it should be okay to leave it as is. |
Beta Was this translation helpful? Give feedback.
-
Hi,
Absolutely love the work that was put into the library, at our company this is the default admin facing solution. In an attempt to minimise the duplicate implementations for our website we are looking to also use some of the components on our user facing views. But since we are quite often working with people facing several types of disabilities we are checking some of the components and found that some of them can be improved in terms of accessibility.
We are wondering that if we were to open up pull request(s) to improve on these areas these will be merged into the core of filament. Some might also be related to our current setup and can be resolved overriding some css. A few areas that might be improved are listed below:
We are considering to implement some or (all) of these ourselves but before putting in the effort we would like to discuss which of the different improvements would be merged into. Mentioning @danharrin to get the discussion going on which of these might be accepted in the form of a PR.
Beta Was this translation helpful? Give feedback.
All reactions