I try
Accessibility is important to Siteimp because websites and applications should be usable by more people, in more situations, with fewer barriers. That sounds simple, but accessibility work is not simple. It takes testing, judgment, humility, repetition, and a willingness to notice when something technically works but still feels awful to use.
Siteimp is built around that kind of practical review. The application collects accessibility evidence during scans, but the product itself is also tested as an interface. Automated checks are useful, but they are not enough on their own. Keyboard testing, screen reader testing, contrast review, and manual inspection are part of the process.
I am not perfect at this. I use screen readers regularly in development, but there are still many moments where I do not know whether I am bad at using the tool, whether the website is bad, whether the application is bad, or whether all three things have quietly joined forces and formed a tiny accessibility goblin committee. That uncertainty is part of why the process matters.
How accessibility fits into Siteimp
Siteimp is a local-first Windows application for inspecting websites, monitoring changes, and collecting evidence about content, performance, accessibility, links, images, and best practices. Accessibility is not a decorative feature added at the end. It affects how the application is designed, how support content is written, and how scan results are explained.
Siteimp now reports on individual Lighthouse accessibility audits rather than hiding everything behind one score. That means the application can show more specific evidence about issues such as missing labels, invalid ARIA, weak contrast, heading order, missing alt text, focus behavior, landmarks, table structure, and other accessibility checks.
Those checks do not replace real accessibility expertise, manual testing, or user feedback. They are evidence. They help point review in a useful direction and make it easier to decide whether a problem likely belongs to page content, a shared component, a template, or a theme-level decision.
Colour and contrast
Accessibility starts early in the design process. For Siteimp, that means paying close attention to colour contrast, especially because the application is built around tables, status pills, cards, links, buttons, and dense technical information.
I calculate contrast ratios for colour combinations used in the product and try to avoid combinations that only look good in ideal conditions. Colour should support meaning, not carry meaning by itself. When colour is used to show state or priority, the interface should still remain usable through labels, text, structure, and other cues.
The goal is not only to pass an automated check. The goal is for text, controls, and status information to remain readable and understandable during real use.
Automated testing
Lighthouse accessibility audits are a regular part of Siteimp development. They help catch common issues and provide a useful baseline for pages, templates, and application views.
Automated testing is especially useful for catching repeated problems. If a shared component has a missing label, invalid role, contrast issue, or broken relationship, that problem can spread across many screens. Finding those repeated patterns is one of the reasons Siteimp itself collects accessibility evidence.
When working in React, I also use accessibility linting where appropriate because problems are cheaper to fix before they become part of a workflow. Linting cannot tell you whether an interaction makes sense, but it can catch a lot of avoidable mistakes before they ship.
Screen reader and keyboard testing
Screen reader testing is part of the development workflow. I use screen readers to understand how pages, controls, headings, dialogs, drawers, tables, and support flows behave when the visual interface is not the primary way through the application.
Keyboard testing is part of that same process. Users should be able to move through the application in a predictable order, reach controls, see focus, activate actions, leave temporary UI, and understand where they are. This matters a lot in an application like Siteimp because the product has deep navigation, scan results, page details, monitoring dashboards, and support workflows.
Automated tools can catch many problems, but they cannot fully answer questions like: does this workflow make sense with a screen reader? Does focus move somewhere useful after an action? Does the heading structure explain the page? Does the table provide enough context? Those questions still need human review.
Support content and plain explanations
Siteimp includes in-app support content because documentation is part of accessibility too. A user should not have to guess what a screen is for, what a result means, or where to go next.
The support content is written one page at a time and is designed to answer three practical questions:
- What is this page for?
- What can I do here?
- How do I use it?
This matters because accessibility is not only code. It is also language, structure, guidance, and reducing confusion. A technically accessible interface can still be hard to use if the product never explains itself.
Rationale
Accessibility testing takes time. It can feel expensive because it is expensive. It adds review steps, changes design decisions, and sometimes forces uncomfortable fixes right when a feature feels nearly finished.
I started taking accessibility seriously because I formed relationships with blind and visually impaired users and saw how often the web made ordinary tasks unnecessarily difficult. Watching people struggle with software I worked on changed how I think about development. Everyone should be able to use software.
Then another thing happened: accessibility testing started making the software better for everyone. It caught strange edge cases. It exposed confusing flows. It forced better structure. It made pages and interfaces more predictable. It reduced the number of times I had to debug something at an hour when no one should be reading stack traces unless legally required.
Accessibility is the right thing to do. It also tends to produce better software: clearer interfaces, stronger structure, better keyboard support, better content, better labels, more resilient components, and fewer assumptions about how people use a product.
Ongoing work
Siteimp is still improving. Accessibility work is not something that gets finished once and placed on a shelf beside the spare HDMI cables. Every new feature, page, component, and support workflow can introduce new barriers.
If you find an accessibility issue in Siteimp or on this website, please contact support. Specific reports are especially helpful: the page or screen, what you were trying to do, what happened, what you expected, and what assistive technology, browser, or input method you were using if that context is relevant.
The goal is steady improvement: better evidence, better testing, better support, and a product that becomes easier to use because accessibility is treated as part of the work rather than an apology after it.