Test your webpages against over 200 website accessibility checks with Silktide’s easy to understand accessibility checker. Compatible with Chrome and Edge.
Hello Product Hunters! 🚀
We've used WAVE, aXe, and every other accessibility toolbar under the sun, but they're clunky and confusing to use.
So we made something we'd be happy to use everyday.
In addition to covering all the accessibility features you find elsewhere - like color contrast, alt text, and landmarks - we pioneered the world's first screen reader simulator. You can experience what it's like to use a screen reader, without having to spend hours learning how.
Would love your feedback and thank you for supporting our mission to make the web a more accessible place!
Oliver Emberton
CEO @ Silktide
I have found screen reader plugins for manual testing, but they can be difficult to turn on and off. Also, I have yet to find one that is compatible with Google Suite products (docs, sheets, etc.).
congratulations oliver, holly, ste, and alex on the launch of the silktide accessibility checker. the screen reader simulator sounds intriguing. can you share more about how this feature was developed and what unique challenges you faced during its implementation?
@mashy Thank you for your kind words! I'd love to dive into this topic as it's very interesting! It may get a little technical though, so put your WebDev hat on!
This feature was developed manually, as there weren't any off-the-shelf solutions for navigating the AOM (Accessible Object Model, similar to the DOM) at the time of development. We experimented with using Chrome's AOM using their Puppeteer framework, but it didn't surface the CSS selectors nor Element references. Therefore, we could use it to navigate but not to highlight parts of the page.
So we wrote our own AOM parser which was very interesting! For example, you don't want to pre-process the entire DOM on load, as some websites are huge, which has a visible performance impact. Instead, our AOM effectively lazy-loads the next element only when necessary.
We also have models for each type of element, like Button/Text/TableHeading/Select etc. This gives us complete control of handling subtle edge cases for each type of element. For example, if a ListItem contains only a single Link, we often want to navigate directly to the Link element, skipping over the ListItem! This can easily be managed by using custom code for each sub type of element.
We ran into various limitations based on the limits of HTML and the DOM itself. E.G. due to JavaScript restrictions we cannot interact with native `select` elements, meaning we can't auto open them, nor can we highlight the options inside of it!
We also cannot currently simulate hovering over elements controlled by CSS `:hover`, as you can't simulate a hover event in JavaScript, and you can't "move the mouse" programatically etc. That means when we highlight your elements, we can't apply hover styles.
We currently have other limitations, but these can be improved over time. For example we struggled to implement all the complex rules for aria-* related HTML attributes. To get around this quickly we rely on the website implementing "focus" correctly, and we simply "follow" the focus when a focus event occurs. This means we can follow users inside custom select boxes and modals etc. It works ok, but it could be improved in a future release! Other challenges involved handling special aria roles, like "window" or "application", as these often have custom navigation key binds etc. This can also be improved in a future release though.
I hope this gave you a taste of what was involved in the development of this feature! We had a great time working on it and cannot wait to improve it over time!