Eduardo Vela
@sirdarckcat.bsky.social
It's covered by the privacy policy, so similar to Docs/GMail!
February 10, 2025 at 6:53 AM
It's covered by the privacy policy, so similar to Docs/GMail!
Yes!!! It would be so cool if they open sourced their tools
February 3, 2025 at 10:17 PM
Yes!!! It would be so cool if they open sourced their tools
I think the FBI is taking a chaotic good approach to secure coding. No more insecure software or.. right to jail!
a man in a military uniform is standing in front of a group of people and says `` right to jail '' .
ALT: a man in a military uniform is standing in front of a group of people and says `` right to jail '' .
media.tenor.com
January 1, 2025 at 11:29 AM
I think the FBI is taking a chaotic good approach to secure coding. No more insecure software or.. right to jail!
github.com
December 24, 2024 at 4:12 AM
So with that, I'll update this thread when I make some progress 🙂
December 23, 2024 at 3:20 PM
So with that, I'll update this thread when I make some progress 🙂
Some I will fix by hiding it from the a11y tree (like the checkboxes), some I will fix by changing divs to buttons (as I should have done since the start). Some I will add aria roles (like for things I styled as links but can't make real links).
Some I'm curious what will happen (like dialogs).
Some I'm curious what will happen (like dialogs).
December 23, 2024 at 3:20 PM
Some I will fix by hiding it from the a11y tree (like the checkboxes), some I will fix by changing divs to buttons (as I should have done since the start). Some I will add aria roles (like for things I styled as links but can't make real links).
Some I'm curious what will happen (like dialogs).
Some I'm curious what will happen (like dialogs).
So, with that, my next step is going to be to look at the *actual* a11y tree of the application and see what's there that shouldn't be there.
Some stuff I already know I will find is:
1. I used some divs as buttons instead of using <button>
2. I used some checkboxes for keeping CSS state
Some stuff I already know I will find is:
1. I used some divs as buttons instead of using <button>
2. I used some checkboxes for keeping CSS state
December 23, 2024 at 3:20 PM
So, with that, my next step is going to be to look at the *actual* a11y tree of the application and see what's there that shouldn't be there.
Some stuff I already know I will find is:
1. I used some divs as buttons instead of using <button>
2. I used some checkboxes for keeping CSS state
Some stuff I already know I will find is:
1. I used some divs as buttons instead of using <button>
2. I used some checkboxes for keeping CSS state
On an older project of mine, I did this exercise of designing with the accessibility tree, and when making the end-to-end tests, I also serialized the a11y tree to identify regressions (Google also has an internal tool called Rembrandt that does this), you can see it here
github.com/google/tampe...
github.com/google/tampe...
December 23, 2024 at 3:20 PM
On an older project of mine, I did this exercise of designing with the accessibility tree, and when making the end-to-end tests, I also serialized the a11y tree to identify regressions (Google also has an internal tool called Rembrandt that does this), you can see it here
github.com/google/tampe...
github.com/google/tampe...
Screen readers actually have better keyboard navigation tools than we do (yikes!), as there are a lot more keyboard shortcuts. However, the majority of the interactions work without assistive technologies. As a result, a significant "upside" about caring about a11y is better keyboard UI design.
December 23, 2024 at 3:20 PM
Screen readers actually have better keyboard navigation tools than we do (yikes!), as there are a lot more keyboard shortcuts. However, the majority of the interactions work without assistive technologies. As a result, a significant "upside" about caring about a11y is better keyboard UI design.
As such, when drafting the a11y tree we can "imagine" what hierarchy is easy to navigate through by landmarks and tabbing. One (surprising?) result is that this makes the webapp extremely keyboard friendly, and in a way, helps users be more productive.
December 23, 2024 at 3:20 PM
As such, when drafting the a11y tree we can "imagine" what hierarchy is easy to navigate through by landmarks and tabbing. One (surprising?) result is that this makes the webapp extremely keyboard friendly, and in a way, helps users be more productive.
Screen readers "navigate" through the accessibility tree, but they also use "landmarks" like headings. And to navigate the hierarchy within the application. Interactive elements (like buttons) also can be sequentially browsed through by tabbing.
December 23, 2024 at 3:20 PM
Screen readers "navigate" through the accessibility tree, but they also use "landmarks" like headings. And to navigate the hierarchy within the application. Interactive elements (like buttons) also can be sequentially browsed through by tabbing.