Make your website more accessible and readable

Start with an automated test to get a score, then look at the pages themselves, because an automated score tells you how much is wrong but not exactly where. Kite does both.

The PageSpeed test runs Google's Lighthouse accessibility checks and gives each page a score out of 100 for mobile and for desktop. Kite can run it on your homepage and on any other page you care about, such as your pricing page or your signup page. It's a quick, repeatable number that makes progress easy to see.

Kite then opens those pages in a browser and reads their structure: the headings, links, buttons, form fields, and images that a screen reader announces. That's where it finds the actual problems. It notes an image of your team with no description, a search icon in the header that a screen reader announces only as "button," an email field with placeholder text but no label, or gray body text on a white background that falls below the contrast people with low vision need. It also views each page at phone width to find text that's too small, buttons too close together to tap, and sections that overflow the screen.

Kite runs this check on any public website, so it works whether Kite hosts your site or not. You can ask it to check a competitor's site too, if you want to see how yours compares.

Kite ranks the problems by how many people they block and how much of the site one fix would repair. That ranking matters more than the length of the list, because a long list of issues usually traces back to a much shorter list of causes.

Shared parts of the site come first. If your brand's light gray is used for body text across the whole site, darkening that one color in the palette fixes the contrast on every page at once. The same goes for a navigation menu, a footer, or a signup form that appears on many pages. Fixing the component once is faster than fixing the pages one by one, and it keeps new pages from inheriting the problem.

Next come the pages and steps where a problem costs you a customer. A missing label on the email field of your signup form, or a "Buy" button a screen reader can't name, stops someone from becoming a customer. Kite also clicks through your main call to action in a real browser to confirm that the path to signing up or buying works from start to finish.

Page-by-page content fixes come last. These include writing descriptions for images, fixing headings that skip levels, and replacing "learn more" links with text that says where they go. They're quick on their own, and Kite works through them starting with your most visited pages.

Kite treats readability as part of the same job, because a page that's hard to read loses visitors even when it passes every automated test. It rewrites copy in your brand voice so it's plainer and easier to scan, without changing what you're saying.

On a typical page, that means:

• breaking long paragraphs into shorter ones that each make one point
• rewriting headings so a visitor who reads only the headings still understands the page
• replacing jargon and long sentences with plain language
• turning dense lists of features into bullets
• making link and button text describe what happens next, such as "See pricing" instead of "Click here"

Kite also adjusts how text looks. It sets body text large enough to read on a phone, gives lines enough spacing, keeps line lengths comfortable on wide screens, and makes sure text over images or colored backgrounds stays legible. On sites it builds, Kite designs with these rules from the start. It uses a proper heading structure, real buttons and links that work with a keyboard, and color pairs with readable contrast.

Clearer structure helps machines read your pages too. Headings that describe their sections, images with descriptions, and plain language make your content easier for AI assistants and search engines to understand and quote. If that's a goal of yours, see Improve your visibility in AI answers.

Kite makes the changes itself, and how it does that depends on where your site runs. On a site Kite builds and hosts, it can change anything, from the color palette and the navigation code to the copy and image descriptions on each page. Each change waits as an unpublished change you can preview. When you publish, Kite shows the list of changes that will ship, publishes them together, and checks that the site still displays correctly. You can undo any single change without losing the others.

If your site's code lives in GitHub, Kite makes the same kinds of changes in your repository. It merges them into your main branch, or opens a pull request if you protect that branch, and your own deployment ships them.

If your site runs on Webflow, WordPress, Contentful, Sanity, or Storyblok, Kite publishes content fixes through your connected account. That covers the copy, headings, and the fields your content system stores, which often include image descriptions. Fixes that live in the site's design or code, such as the theme colors, need someone with access to that code. In that case, Kite writes up exactly what to change and why, so your developer or agency can make the change quickly.

Kite keeps a record of every problem it found, which ones it has fixed, which are live, and which are still open. It can publish that record as a report at a shared link, grouped by page and by cause, and update it as each round of fixes ships. That gives you one place to see progress, and it gives you documentation of the work if anyone asks what you've done to make the site accessible.

After a round of fixes goes live, Kite runs the PageSpeed test and the browser check again on the same pages and compares the results with the earlier run. You see the score change on mobile and desktop and which problems dropped off the list.

New pages and edits can bring old problems back, so it helps to check regularly. Ask Kite to repeat the check on a schedule, such as once a month, and it runs the same pages each time and tells you what changed. The results arrive in the Kite web app, in Slack if you've added Kite there, or by email.