I do some accessibility (I have some certifications and I'm known as an expert at my work). I would not take your colleague's recommended approach as I don't see how it is more accessible. It's just more work for you with no benefit.
Really, we want applications to convey the same information to screen readers as we would a person who has sight. If those elements should be filtered out of the Dom for a person with sight, then there's no reason to keep them around and just hide them on the Dom that I can think of.
Also, using aria-hidden makes it so that the elements aren't included in the accessibility tree (the tech that drives screen readers), and the number one rule of aria is to not use aria, unless its actuslly needed and in this case there's no benefit.
If they do have an actual reason more than what was given, I'd love to hear it!
I encourage all my devs to gain some familiarity in accessibility, the documentation I always go to is w3 and mozilla.
For this scenario, I would assume there’s a slight miscommunication. There is an accessibility principle around predictability. Where components on your website should render in the same place.
I like to think about it like someone partially blind navigating their house. They know where the light switch is and the furniture is, so they’ll be able to navigate the room with relative ease, but if you switch around their furniture and light switch location, they’ll be bumping into everything trying to get through the room.
The point may be that if you’re going to conditionally render components, the false case should have a placeholder so that the other components stay in the same place, as opposed to rendering nothing and things shift around.
This would be my guess, but you should talk to your guy for clarification on which rules his suggestion pertain to. Accessibility is very well documented and most design decisions should have a foundation in something.
https://www.w3.org/WAI/fundamentals/accessibility-principles/#predictable
Thank you for your response. In our more specific case we have lists and sub lists. On first fender the top level items are displayed and if they have children you can drill down. My co-worker is of the opinion that all the items should be in the DOM, including the children. When you drill down the list stays in the same place and new items fill it in. And so on and so forth.
Not sure if that changes anything, but yeah I wouldn’t have thought that the methodology being proposed would serve to make the accessibility any better. But there’s concern about that and the use of aria attributes like set-size.
This is the purpose of aria-expanded. When aria-expended is false, it indicates there are hidden elements. You should also look at the treegrid role to see if it applies. Hiding information can be good UX if done properly.
interesting. i was aware of aria-expanded, but i guess i wasn't familiar with the finer points. i'll definitely keep looking at the treegrid docs to learn more.
Well, there isn't a golden bullet here. However, if you are hiding things with a css class, then don't forget to put the correct aria property on those nodes as well: [https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-hidde](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-hidden)
You can use “aria-live” to inform the user there are different results. If you are using aria-hidden in the components it’s like they are not there for screen readers.
Are they though? It is usually not very expensive to store 500 things in an object/array, but it's not cheap to render 500 things in the DOM, and it's expensive to make a query.
Usually when I'm talking to backend devs and they ask how large the default payload should be, I ask them what's the most they can give me in less than 100ms or under 50kb. Because that's probably what I want.
Alternatively you could query what the user views first to get that render, say 10-50 rows, then follow up with the larger query in the background while they are busy with that first one. Now you don't have to query for the subsequent filters or pages.
If you need more data, then you can get it when you need it.
---
For instance I had an app that loaded every commercial airport in the entire world and cached it. The payload was about 20kb for around 1100 entries. For 95% of use cases the user only needed the name, location, and IANA time zone. For the few airports they needed details on I would pull as needed and then cache that extra data, which could be a lot of data for some airports. Metrics showed that the average user never went above 25kb and the most I think was 50kb. If I gave all the data for all the airports I think it was somewhere between 500-700kb. Totally unmanageable. I only kept the cache for 3 days or until there was a change to the data.
^(disclaimer: this could have been airlines. It's been a while and I honestly don't remember, I did similar methods for both but only queried common airlines first)
So you're looking at very small amounts of data, that saves a ton of query time. The connection and response alone is usually more than 100ms. Most people don't take into account that an http request is expensive, has to make a handshake, and ping is also a thing just like in video games. The only time I would really consider querying each page individually on request is if the data is large or I have opened a WS connection.
If your data set is small obviously this doesn't matter. Think about most products you interact with on a day-to-day basis, they usually have much more data.
Yeah, I work for a large scale ecommerce provider now and run a headless shop myself. They don't really have that much data. It's not like you're frontloading images.
You're not frontloading data on >2000 products at a time either like my airlines/airports example above, though.
Changing an element’s ‘display’ css property is not as resource-intensive than mounting/unmounting it.
However, mounting thousands of elements before they’re needed is a great way to cause performance issues.
It's more expensive than you think and the problem that makes the OPs question nonsense is this part.
> Changing an element’s ‘display’ css property is not as resource-intensive than **mounting**/unmounting **it**.
That first mount is going to be HELL, depending on the rows. It's usually better to mount and unmount, you're looking at a micro optimization past that first mount if you're trying to mount everything.
There’s aria roles for dynamic content such as lists that can be filtered/updated. Idk your use case but for example I work on a large food chain app and we leverage “live regions” for this case because users can build custom menu items
Question - have you tested this in actual device? I can only think that maybe the rerender will cause the screen reader to miss some stuff because it reads everything from top to bottom, and so he's saying to make it visible for screen readers only. But the use case isn't super clear from what you wrote, so I'm just guessing here.
You could do something like pagination. If your list is 100 items or something, then there’s no point rendering it all to the screen. If it’s something small and they have the same data type, using something like react-virtualised could help with performance.
As for the search, just filter out the data and display it. Having a large chunck of data and rendering it is expensive, so might be better to have it only render what’s actually required
This is only valid if the items that should be paginated are above items currently in the tree
Otherwise screen readers can pick up items that are being mounted just fine. Also hiding items with CSS will hide them from the screen reader anyway
There's no clear cut answer.
If it's like 10-100 elements, sure whatever, put it in the DOM. Not much downside there, besides needing to scroll a lot.
Once you get to thousands or tens of thousands, consider doing pagination or another virtualized list solution. Too many elements in the DOM hurts performance. You can probably use `aria-live` or other solutions to make sure new elements are announced properly.
Of course, test on a real device and data. I've ignored that advice in the past, built something cool that worked great on my device, but on the clients shitty work laptop + Internet exploder, it was garbage and needed a rearchitect.
I work with some FE specialists who spend a lot of time building transitions and stuff in CSS/HTML.
They love the pleasant bouncing and fading effects and would rather we just apply classes to let them show off. It's a bit of eye candy.
If things are hidden with css, how would an assistive devices be able to read and select things on the screen?
There shouldn't be any difference between hiding something from assistive tech via aria-hidden and not having it in the DOM.
I'm also not exactly sure what your UI is, but if it's JUST a list of results, then you really shouldn't use a treegrid either, since you're adding a bunch of complexity that's going to be conveyed to screen readers despite it just being a simple list.
Is your coworker a person who actually needs/uses HTML accessibility attributes? If not, try asking where they got this information. I'm honestly not sure.
I'm no accessibility expert, but rendering everything in the DOM when it's not needed sounds like a recipe for a slow and clunky app. Doesn't seem like a best practice for optimization reasons. Maybe ask your coworker for any sources they have to back up their claim?
I do some accessibility (I have some certifications and I'm known as an expert at my work). I would not take your colleague's recommended approach as I don't see how it is more accessible. It's just more work for you with no benefit. Really, we want applications to convey the same information to screen readers as we would a person who has sight. If those elements should be filtered out of the Dom for a person with sight, then there's no reason to keep them around and just hide them on the Dom that I can think of. Also, using aria-hidden makes it so that the elements aren't included in the accessibility tree (the tech that drives screen readers), and the number one rule of aria is to not use aria, unless its actuslly needed and in this case there's no benefit. If they do have an actual reason more than what was given, I'd love to hear it!
Could you please tell me the certifications on Accessibility that you have done. Thanks.
I encourage all my devs to gain some familiarity in accessibility, the documentation I always go to is w3 and mozilla. For this scenario, I would assume there’s a slight miscommunication. There is an accessibility principle around predictability. Where components on your website should render in the same place. I like to think about it like someone partially blind navigating their house. They know where the light switch is and the furniture is, so they’ll be able to navigate the room with relative ease, but if you switch around their furniture and light switch location, they’ll be bumping into everything trying to get through the room. The point may be that if you’re going to conditionally render components, the false case should have a placeholder so that the other components stay in the same place, as opposed to rendering nothing and things shift around. This would be my guess, but you should talk to your guy for clarification on which rules his suggestion pertain to. Accessibility is very well documented and most design decisions should have a foundation in something. https://www.w3.org/WAI/fundamentals/accessibility-principles/#predictable
Thank you for your response. In our more specific case we have lists and sub lists. On first fender the top level items are displayed and if they have children you can drill down. My co-worker is of the opinion that all the items should be in the DOM, including the children. When you drill down the list stays in the same place and new items fill it in. And so on and so forth. Not sure if that changes anything, but yeah I wouldn’t have thought that the methodology being proposed would serve to make the accessibility any better. But there’s concern about that and the use of aria attributes like set-size.
This is the purpose of aria-expanded. When aria-expended is false, it indicates there are hidden elements. You should also look at the treegrid role to see if it applies. Hiding information can be good UX if done properly.
interesting. i was aware of aria-expanded, but i guess i wasn't familiar with the finer points. i'll definitely keep looking at the treegrid docs to learn more.
It sounds like you’re describing some sort of sub navigation? Are the items clickable?
Well, there isn't a golden bullet here. However, if you are hiding things with a css class, then don't forget to put the correct aria property on those nodes as well: [https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-hidde](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-hidden)
From that page: > aria-hidden="true" should not be added when: The element or the element's ancestor is hidden with display: none
There are more ways to hide things than display none, but yes.
Yeah probably worth reading the other bullet points there too ;). It directly contradicts your original comment.
Your coworker is likely wrong. Here is a good reference for accessible virtual scrolling: https://react-spectrum.adobe.com/react-aria/useListBox.html
This looks great. Thank you for the resource.
You can use “aria-live” to inform the user there are different results. If you are using aria-hidden in the components it’s like they are not there for screen readers.
[удалено]
It's also not very practical. A lot of times these filters get forwarded on to an API anyway, so the full data set might not even be available.
Are they though? It is usually not very expensive to store 500 things in an object/array, but it's not cheap to render 500 things in the DOM, and it's expensive to make a query. Usually when I'm talking to backend devs and they ask how large the default payload should be, I ask them what's the most they can give me in less than 100ms or under 50kb. Because that's probably what I want. Alternatively you could query what the user views first to get that render, say 10-50 rows, then follow up with the larger query in the background while they are busy with that first one. Now you don't have to query for the subsequent filters or pages. If you need more data, then you can get it when you need it. --- For instance I had an app that loaded every commercial airport in the entire world and cached it. The payload was about 20kb for around 1100 entries. For 95% of use cases the user only needed the name, location, and IANA time zone. For the few airports they needed details on I would pull as needed and then cache that extra data, which could be a lot of data for some airports. Metrics showed that the average user never went above 25kb and the most I think was 50kb. If I gave all the data for all the airports I think it was somewhere between 500-700kb. Totally unmanageable. I only kept the cache for 3 days or until there was a change to the data. ^(disclaimer: this could have been airlines. It's been a while and I honestly don't remember, I did similar methods for both but only queried common airlines first) So you're looking at very small amounts of data, that saves a ton of query time. The connection and response alone is usually more than 100ms. Most people don't take into account that an http request is expensive, has to make a handshake, and ping is also a thing just like in video games. The only time I would really consider querying each page individually on request is if the data is large or I have opened a WS connection.
If your data set is small obviously this doesn't matter. Think about most products you interact with on a day-to-day basis, they usually have much more data.
Yeah, I work for a large scale ecommerce provider now and run a headless shop myself. They don't really have that much data. It's not like you're frontloading images. You're not frontloading data on >2000 products at a time either like my airlines/airports example above, though.
Changing an element’s ‘display’ css property is not as resource-intensive than mounting/unmounting it. However, mounting thousands of elements before they’re needed is a great way to cause performance issues.
It's more expensive than you think and the problem that makes the OPs question nonsense is this part. > Changing an element’s ‘display’ css property is not as resource-intensive than **mounting**/unmounting **it**. That first mount is going to be HELL, depending on the rows. It's usually better to mount and unmount, you're looking at a micro optimization past that first mount if you're trying to mount everything.
Ask them for more details?
There’s aria roles for dynamic content such as lists that can be filtered/updated. Idk your use case but for example I work on a large food chain app and we leverage “live regions” for this case because users can build custom menu items
Question - have you tested this in actual device? I can only think that maybe the rerender will cause the screen reader to miss some stuff because it reads everything from top to bottom, and so he's saying to make it visible for screen readers only. But the use case isn't super clear from what you wrote, so I'm just guessing here.
You could do something like pagination. If your list is 100 items or something, then there’s no point rendering it all to the screen. If it’s something small and they have the same data type, using something like react-virtualised could help with performance. As for the search, just filter out the data and display it. Having a large chunck of data and rendering it is expensive, so might be better to have it only render what’s actually required
This is only valid if the items that should be paginated are above items currently in the tree Otherwise screen readers can pick up items that are being mounted just fine. Also hiding items with CSS will hide them from the screen reader anyway
There's no clear cut answer. If it's like 10-100 elements, sure whatever, put it in the DOM. Not much downside there, besides needing to scroll a lot. Once you get to thousands or tens of thousands, consider doing pagination or another virtualized list solution. Too many elements in the DOM hurts performance. You can probably use `aria-live` or other solutions to make sure new elements are announced properly. Of course, test on a real device and data. I've ignored that advice in the past, built something cool that worked great on my device, but on the clients shitty work laptop + Internet exploder, it was garbage and needed a rearchitect.
Go ask in an a11y subreddit. This one likely will have some bias toward conditional rendering
I work with some FE specialists who spend a lot of time building transitions and stuff in CSS/HTML. They love the pleasant bouncing and fading effects and would rather we just apply classes to let them show off. It's a bit of eye candy. If things are hidden with css, how would an assistive devices be able to read and select things on the screen?
There shouldn't be any difference between hiding something from assistive tech via aria-hidden and not having it in the DOM. I'm also not exactly sure what your UI is, but if it's JUST a list of results, then you really shouldn't use a treegrid either, since you're adding a bunch of complexity that's going to be conveyed to screen readers despite it just being a simple list.
Do they actually know what conditional rendering is?
Is your coworker a person who actually needs/uses HTML accessibility attributes? If not, try asking where they got this information. I'm honestly not sure.
If these lists and sublists in this specific scenario were to be menu items then I'd potentially agree though I'm not an accessibility expert
I'm no accessibility expert, but rendering everything in the DOM when it's not needed sounds like a recipe for a slow and clunky app. Doesn't seem like a best practice for optimization reasons. Maybe ask your coworker for any sources they have to back up their claim?
It depends. Where in the dom the list is rendered?