Accessibility

The standard we build to

This site targets Web Content Accessibility Guidelines 2.2, Level AA, published by the W3C. That is the version most commonly referenced by the Americans with Disabilities Act in the United States, by EN 301 549 in the European Union, and by accessibility regulations in the UK.

We build to 2.2 rather than the older 2.1 deliberately. Version 2.2 added several criteria that matter a great deal on a site like this one, and most small business sites still stop at 2.1 without saying so.

What that means in practice

These are enforced by the build. If any of them break, the site does not deploy.

Color and contrast

Every text and interface color pairing in the design is checked against the real WCAG contrast formula on every build. Normal text meets at least 4.5 to 1. Large text, control borders, and focus indicators meet at least 3 to 1. The lowest ratio anywhere in the system is 4.49 to 1, against a 3 to 1 requirement.

Both the light and dark versions of the site are checked. Dark mode is where this most often goes wrong on other sites, because designers verify the light palette and assume the dark one inherits it.

Keyboard and focus

• Everything you can do with a mouse, you can do with a keyboard alone.
• Focus is always visible, with a three pixel indicator that meets contrast requirements on every surface it can land on.
• A skip link is the first thing you reach, so you can jump past the navigation.
• The sticky header never covers the element you just moved focus to. This is criterion 2.4.11, new in WCAG 2.2, and it is the single most commonly missed one on sites with a fixed header.

Targets and pointers

• Every link and button is at least 24 by 24 pixels, which is criterion 2.5.8, also new in 2.2. Primary buttons are 44 pixels.
• Nothing on this site requires a dragging motion to operate, which satisfies criterion 2.5.7.

Forms

• Every field has a real visible label. We never use placeholder text as a label, because it disappears the moment you type and usually fails contrast anyway.
• Errors are described in words next to the field, not signalled by color alone.
• We do not use a CAPTCHA. A CAPTCHA is a cognitive function test, and under criterion 3.3.8, also new in 2.2, one cannot stand between you and a form without an accessible alternative. Spam is handled invisibly instead.
• We do not ask you to re enter information you already gave us in the same process, which is criterion 3.3.7.

Structure and content

• Real headings in a logical order, real landmarks, and real lists, so a screen reader can navigate by structure.
• Meaningful images have alt text describing what matters about them. Purely decorative images are marked so screen readers skip them. The build fails if an image is added without a deliberate choice either way.
• The page language is declared, so screen readers use the right pronunciation.
• The layout reflows to a 320 pixel wide screen and to 400 percent zoom without a horizontal scrollbar.
• If your system asks for reduced motion, this site honors it.
• Help is in the same place on every page, which is criterion 3.2.6.

How we test

Automated tools catch somewhere around a third of real accessibility problems. Anyone who tells you their site is accessible because a scanner returned zero errors is telling you they ran a scanner.

On every build we run automated checks for contrast, structural requirements, and markup validity. Beyond that we manually walk the whole site with the keyboard only, check it with a screen reader, view it at 400 percent zoom, and confirm it works with a forced high contrast mode.

Where we fall short

Listing nothing here would not be honest. Every site has rough edges.

• Embedded maps. Where we embed a third party map, we do not control its internal accessibility. Every address and service area is also written out in plain text on the page so the map is never the only way to get the information.
• Photographs of finished work. Alt text describes what the picture shows, but a photo of a finished lawn or a mounted display carries detail that is genuinely hard to convey in a sentence. If a specific image matters to you and the description is not enough, ask and we will describe it properly.
• Documents. Any PDF estimate or invoice we send is generated by third party software and may not be fully tagged. Ask and we will send the same information as plain text or in the body of an email.

If something does not work

Tell us. This matters more than the rest of this page.

You do not need to know the technical name for the problem or which guideline it falls under. Saying that you could not get the form to work with your keyboard, or that the text was too small to read, is exactly the right amount of detail.

Email shaunds1983@outlook.com or call (720) 681-4380. We aim to reply within every request answered within 4 business hours.

If something on this site is stopping you from getting a quote, tell us what you need and we will simply take the details over the phone or by email instead. You should never have to fight a website to hire someone.

Compatibility

This site is built and tested to work with current versions of Chrome, Edge, Firefox, and Safari on desktop and mobile, with recent versions of the NVDA, JAWS, VoiceOver, and TalkBack screen readers. It is plain HTML and CSS with a very small amount of JavaScript, so it also works acceptably in older browsers and with JavaScript turned off entirely.