In short and in plain language
Many firms must make their website usable for all people. This includes people with a disability. A law has asked for this since the end of June 2025.
You can do a first test on your own. You only need your browser and your keyboard. You do not need an extra program.
Try this, for example: Does everything work without a mouse? Can you zoom the page up? Do videos have captions? Do you get a clear message when you send a form with empty fields?
But the test does not find everything. You cannot tell how a screen reader reads the page out. You can only check colors roughly this way.
So experts should check the page in detail after that. They check all the rules. They write down what needs to change.
The German Accessibility Strengthening Act (BFSG) applies to certain services provided to consumers after 28 June 2025, including e-commerce services (BFSG § 1), and since then many site owners have been asking the same question: how accessible is my website, really? The reliable answer comes from an audit. You can form a first impression yourself, though, with nothing more than a browser, a keyboard and a notepad. The W3C put together its "Easy Checks" for exactly this purpose: short checks to get started, which explicitly do not replace a full evaluation (W3C Easy Checks). This article turns them into eight hands-on checks you can run on your own website without extra software, and it draws the line as clearly as the W3C does: what the self-check shows, what it can only estimate roughly and what it cannot see at all.
Key takeaways
- The W3C's quick checks cover only a few barriers: a page can pass them and still have significant accessibility barriers (W3C Easy Checks). A self-check points the way; it is not proof of conformance.
- Check without a mouse: every function must be operable through the keyboard, using Tab, Shift+Tab, Enter, Space, the arrow keys and Escape, and the focus must be visible (W3C WCAG 2.2).
- Zoom to 200 percent in a narrow window: text stays readable, nothing overlaps and no horizontal scrolling is needed. Pressing Ctrl and plus five times should get you there (W3C Easy Checks).
- Low text contrast appears on 83.9 percent of the top one million home pages (WebAIM Million 2026). Without a tool it can only be judged roughly in grayscale; the 4.5:1 ratio (W3C WCAG 2.2) takes a tool to measure.
- A form submitted empty reveals a lot: every error message must name the affected field and describe the error in text (W3C WCAG 2.2), and required fields need a visible indicator.
- No self-check finds screen reader output, ARIA states or focus handling in dialogs. Offering a service contrary to Section 14 (1) BFSG risks a fine of up to 100,000 euros (BFSG § 37).
What a self-check can do
The W3C describes its Easy Checks as a starting point: simple checks tell you whether accessibility has been addressed on a page in even the most basic way. In the same breath it warns that the checks cover only a few issues, are designed to be quick rather than exhaustive, and that a page can pass them and still contain significant barriers (W3C Easy Checks). That limit applies to everything that follows in this article. A passed self-check is not a sign-off. A failed one, on the other hand, is a clear signal that action is needed.
Why the effort still pays off is shown by the WebAIM Million 2026. On 95.9 percent (WebAIM Million 2026) of the home pages of the top one million websites, the automated evaluation found WCAG failures. 96 percent (WebAIM Million 2026) of all detected errors fall into just six types: low text contrast, missing alternative text, missing form labels, empty links, empty buttons and a missing document language. Four of these six can be tracked down at least roughly with the checks in this article. Empty links and buttons, by contrast, only show up once a screen reader or a tool reads out the name of a control.
Official statistics show who the checks are for. At the end of 2025, just over 7.8 million (Destatis) people with severe disabilities lived in Germany, which is 9.4 percent (Destatis) of the population. In 4 percent (Destatis) of cases the disability was blindness or visual impairment, and in another 4 percent (Destatis) it was hearing loss, balance or speech disorders. The statistics only count people whose severe disability has been officially recognized. Anyone who forgot their reading glasses, can only use the keyboard because of a cast or watches a video on the train with the sound off appears in no table and benefits from the same fixes.
What "without tools" means here
Preparation: three pages and a checklist
Do not test the whole website; test three pages that matter for your business: the home page, a typical content or product page and the page with your most important form, such as contact, appointment booking or the first step of checkout. Work in the browser you use every day, and do not close the cookie banner with the mouse beforehand. How it works with the keyboard is already part of the first check. For every finding, write down five things:
- Page and address: which of the three pages, with the full URL.
- Check: which of the eight checks, for example "zoom" or "submit form empty".
- Observation: what exactly happened, in one sentence and without judgment, such as "menu does not open with Enter".
- Screenshot: with the focus or error message visible, so that developers or your agency can reproduce the finding.
- Impact: does the issue block a task, make it harder or merely get in the way?
Impact is the most important field. A contact form that cannot be submitted without a mouse weighs more than pale text in the footer. Keep observation and impact apart: the observation describes what you saw, the impact what it means for a person who relies on the keyboard, magnification or captions.
Check 1: keyboard only
Put the mouse aside, reload the home page and press Tab once. On a well-built page a link such as "Skip to content" now appears. It is the first interactive element and takes you past the menu and search straight to the main content. Designers may hide it until it receives focus, as long as it then becomes clearly visible (W3C Easy Checks). A skip link is a common way to make repeated blocks bypassable, as success criterion 2.4.1 requires (W3C WCAG 2.2). Among the top one million home pages, only 17.1 percent (WebAIM Million 2026) had such a link, and one in ten of those was broken (WebAIM Million 2026), for example because its target was missing.
Then keep pressing Tab to move through the page, and Shift+Tab to go back. Every function must be operable through the keyboard, and the focus, meaning the outline or highlight on the element you have just reached, must be visible (W3C WCAG 2.2). Watch for these points:
- Every link, button and form field can be reached, including the cookie banner, search and the cart.
- The focus can be seen at every point. If it disappears, it often sits on an invisible element or was removed by styling.
- Menus, disclosures and tabs open with Enter or Space, and the arrow keys move within select lists.
- Escape closes dialogs and overlays, and you can leave every element again without getting stuck in a loop.
- The focus does not disappear behind a sticky header, a chat window or the cookie banner.
- The order follows the reading flow and does not jump across the page.
Two of these points have their own criteria in WCAG 2.2: you must be able to move focus away from any element using the keyboard (criterion 2.1.2), and a focused element must not be entirely hidden by content on the page (criterion 2.4.11) (W3C WCAG 2.2). More on focus order, keyboard patterns and focus styling is in the article on keyboard navigation. How skip links and menus should be built is covered in the article on accessible navigation.
Check 2: zoom to 200 percent
Shrink the browser window to roughly half the screen width and press Ctrl and plus, or Cmd and plus on a Mac. Doing it five times should bring you to 200 percent (W3C Easy Checks). The value is not arbitrary: text must be resizable without assistive technology up to 200 percent (W3C WCAG 2.2) without loss of content or functionality. Ctrl and zero takes you back to the usual size.
Read the enlarged page from top to bottom. The check is passed if all text stays readable, nothing disappears behind other text or images and you do not have to scroll horizontally to finish reading a line. A main menu that turns into an icon you can open is explicitly fine (W3C Easy Checks). Typical findings are cut-off buttons, overlapping blocks of text in banners and dialogs whose close button slips out of the visible area.
If you want to go further, zoom to 400 percent. In a window 1,280 CSS pixels wide, this corresponds to a view 320 CSS pixels wide (W3C WCAG 2.2), roughly a small smartphone. This tests criterion 1.4.10: content should reflow instead of running off the side of the screen. Text in images only gets blurrier and does not wrap. Why promotional banners should therefore be built in HTML is explained in the article on text in images.
Check 3: turn images off
Alternative text is the short description that conveys the purpose of an image to people who cannot see it (W3C Easy Checks). On 53.1 percent (WebAIM Million 2026) of the home pages examined, it was missing from at least one image. For a blind visitor, a promotional image without text is a gap, and a linked logo without text is a link without a recognizable destination.
Without extra software, you get closer by switching images off. Many browsers let you block images for a website, usually through the site settings or the developer menu. Reload the page and ask yourself at every spot where an image used to be: is any information missing now? Is there text in place of a promotional banner, a price tag or an icon button that does the same job? Purely decorative images may disappear without replacement; for those the W3C explicitly calls for an empty alt attribute (W3C Easy Checks).
This check has a weakness you should know about: browsers display alternative text differently, some only when there is enough space. If a spot stays empty, note it as a suspicion, not a finding. Whether existing text is actually well written is a human judgment anyway. What good alternative text for product images, graphics and linked images looks like is covered in the article on alt text.
Check 4: page title and language
The page title appears in the browser tab and in search results, and it is the first thing a screen reader says when a page opens (W3C Easy Checks). Open several of your pages side by side and read the tabs. Every page needs its own title that describes its topic or purpose (W3C WCAG 2.2). The important part goes first: "Contact - Company name" helps more than a long brand name in front of every page. A title such as "Home" on every subpage is a clear finding.
Right next to it is the language of the page. Screen readers and text-to-speech functions need it to pronounce words correctly (W3C Easy Checks). Right-click, choose "View page source" and look for the html element with lang="en" or lang="de" in the first lines. On 13.5 percent (WebAIM Million 2026) of home pages this attribute was missing. An English passage within a German page would need its own language attribute; the simple check does not detect such changes (W3C Easy Checks).
Check 5: headings as an outline
Headings work like a table of contents. They structure the page, and levels should not be skipped as sub-headings are created (W3C Easy Checks). For screen reader users they are the most important way to find their bearings. A survey of screen reader users with 1,539 (WebAIM Screen Reader Survey 2024) valid responses asked what they are most likely to do first to find information on a lengthy page: 71.6 percent (WebAIM Screen Reader Survey 2024) of those who answered the question named navigating through the headings.
Without a tool, start with the visible outline. Read only the large, bold lines: do they form an understandable overview on their own? Does each one describe the section below it? Then look at the code. In the page source, use Ctrl+F to search for <h1, <h2 and <h3. The main heading usually carries the top level and the following sections the levels below, and an h2 is followed by an h3, not directly by an h4 (W3C Easy Checks). The WebAIM Million found skipped levels on 41.8 percent (WebAIM Million 2026) of home pages and no headings at all on 7.5 percent (WebAIM Million 2026).
This check has a limit. The page source shows the HTML that the server delivers. Anything scripts insert later in the browser, such as filters, tabs or sections loaded on demand, is not there. A visible heading that is missing from the source is therefore a hint, not proof.
Check 6: judge contrast roughly
Low text contrast is the most common automatically detected error: it was found on 83.9 percent (WebAIM Million 2026) of home pages, at an average of 34 (WebAIM Million 2026) spots per page. The usual suspects are light gray hint text, placeholders in input fields, white text on photos and colored buttons.
Without a tool, the grayscale test is what you have. Windows and macOS both offer a color filter in their accessibility settings that shows the screen in grayscale. The W3C explicitly calls this a rough check of whether text is easy to read or needs more contrast (W3C Easy Checks). Whatever blurs in grayscale also loses definition for many people with low vision. Also check whether links can only be told apart from body text by their color, and whether an error notice relies on the color red alone.
For the exact value, the W3C points to tools that calculate the ratio (W3C Easy Checks). Normal text needs a contrast ratio of at least 4.5:1 (W3C WCAG 2.2), large text at least 3:1 (W3C WCAG 2.2). Whether a gray sits just above or just below that threshold is something nobody can see with the naked eye. That is why contrast is the only check on the checklist marked "rough only". The basics of measuring it are explained in the article on color contrast.
Grayscale is not a measurement
Check 7: submit the form empty
Forms are where visitors become customers, and at the same time a frequent source of errors. 51 percent (WebAIM Million 2026) of home pages had at least one input field without a proper label. Start with what you can see: is there a permanent label beside or above every field that says what to enter? A gray placeholder inside the field that disappears as you type does not replace it.
Next comes a simple move from the Easy Checks: click on the label. If the field is correctly associated with it, the cursor jumps into the field (W3C Easy Checks). If nothing happens, what is often missing is exactly the association a screen reader needs to announce the field. For checkboxes and radio buttons, the association also enlarges the clickable area, which helps people with limited dexterity (W3C Easy Checks).
Now submit the form empty, ideally using only the keyboard. If an input error is automatically detected, the field in error must be identified and the error described in text (W3C WCAG 2.2). A field with a red border and no text does not meet that. Also check whether required fields are visibly marked in advance. The W3C recommends including the word "required" in the label, because screen readers often skip an asterisk as punctuation and people with low vision easily miss it (W3C Easy Checks).
If you run a checkout, repeat the check at every step up to payment, without placing a real order. More on labels, error messages and validation rules is in the article on accessible forms.
Check 8: video with the sound off
Mute the sound and start every video on the three pages. Can you see captions, or can you turn them on with a button in the player, often labeled "CC"? Criterion 1.2.2 requires captions for prerecorded video (W3C WCAG 2.2). In the W3C's assessment, auto-generated captions alone are not sufficient (W3C Easy Checks).
If captions are there, check their quality: are punctuation and capitalization right, are they in sync with the speech, can you tell who is speaking, and are important sounds such as applause or thunder included (W3C Easy Checks)? Audio-only content such as podcasts needs a transcript. Videos whose visuals matter for understanding need audio description that explains what is shown.
For older videos, the law is worth a look: prerecorded time-based media published before 28 June 2025 are explicitly excluded from the BFSG (BFSG § 1). Anything published after that date does not fall under this exception. How captions, transcripts and audio description are produced in practice is described in the article on accessible media.
The checklist at a glance
The table sums up the eight checks. The right-hand column names the success criteria according to WCAG 2.2 that a check mainly relates to (W3C WCAG 2.2). A passed check does not mean the criterion is met; it only means that nothing obvious stands out at that spot.
| Check | Action | Passed if | WCAG 2.2 |
|---|---|---|---|
| Keyboard | Tab, Shift+Tab, Enter, Space, Escape | everything reachable, focus visible, no trap | 2.1.1, 2.1.2, 2.4.7 |
| Zoom | Ctrl or Cmd and plus, five times | text readable, nothing overlaps, no horizontal scrolling | 1.4.4, 1.4.10 |
| Images off | block images for the site, reload | no information missing, decorative images may go | 1.1.1 |
| Page title and language | read the tabs, open the source | unique, descriptive title, language attribute present | 2.4.2, 3.1.1 |
| Headings | read the bold lines, search the source for h1 to h3 | clear outline without skipped levels | 1.3.1, 2.4.6 |
| Contrast (rough only) | grayscale filter of the operating system | text easy to read in gray too, exact value needs measuring | 1.4.3 |
| Form | click the label, submit empty | cursor jumps into the field, error appears as text at the field | 3.3.1, 3.3.2 |
| Video | sound off, captions on | complete, synchronized captions, not only auto-generated | 1.2.2 |
What a self-check does not find
The line runs where accessibility is no longer visible. A screen reader does not read the screen; it reads the name, role and state of every control from the code. For all user interface components, name and role must be programmatically determinable, and so must states and changes to them (W3C WCAG 2.2). Whether a disclosure menu is announced as "expanded" or whether a button with a magnifier icon has a name is not something you can see by looking at it.
Screen reader flow
Whether titles, headings, links and form fields are announced in a sensible order and with understandable names is only audible to someone who goes through the page with a screen reader.
ARIA states
Expanded, selected, pressed: such states live in the code. If they are missing or do not change as you operate the control, nothing on the screen shows it.
Focus in dialogs
A dialog has to take the focus, hold it until it closes and then return it to the element that opened it. That takes a practiced pass with keyboard and screen reader.
Status messages
Messages such as "Item added" or "No results" have to be announced by a screen reader without the focus moving. Whether that happens is not visible on screen.
Measured values
Contrast ratios and target sizes of at least 24 by 24 CSS pixels (W3C WCAG 2.2) are measurements, not a matter of eyeballing. The self-check only gives you a suspicion here.
Behind the login
Customer accounts, PDF invoices and payment steps fall outside a check on three public pages, yet they are part of the service.
Tools only partly close this gap. The WebAIM Million itself stresses that no automated test detects all conformance failures and that a page without detected errors is not accessible for that reason alone (WebAIM Million 2026). What testing software, keyboard tests and screen readers each contribute is laid out in the article on testing methods. For screen reader output we offer a dedicated screen reader test.
Record and rank your findings
After the eight checks you have a list. Sort it by impact, not by check. At the top goes everything that blocks a task, such as a form that cannot be submitted without a mouse or a cookie banner that cannot be closed with the keyboard. Next comes what makes a task harder, and last what merely gets in the way. This order helps developers or your agency more than any score.
Hand over the list with screenshots and ask for every finding to be mapped to a success criterion. Many findings share a cause in a template or component. Once the component is fixed, they disappear on every page at once. How a list of findings becomes a plan with waves and clear ownership is described in the article from audit report to remediation plan.
The question behind all eight checks
Repeat the self-check after every major change: a new banner, a new form, a new video, a new template. It takes little time and catches regressions before a customer complains or an authority starts asking questions.
From self-check to audit
The BFSG does not ask whether a page passes a self-check. Under the law, a service is accessible if people with disabilities can find, access and use it in the usual way, without particular difficulty and, as a rule, without help from others (BFSG § 3). A service provider may only offer its service if it meets the requirements (BFSG § 14). Anyone in breach risks a fine of up to 100,000 euros (BFSG § 37). Which requirements apply in detail is summarized on the page on BFSG requirements.
Micro-enterprises that offer services are exempt (BFSG § 3), meaning companies with fewer than ten employees and an annual turnover or balance sheet total of no more than 2 million euros (BFSG § 2). Whether the exemption applies to you is explained in the article on the micro-enterprise exemption. For everyone else, the self-check is a good start and a poor finish.
A WCAG audit picks up where the eight checks stop. It evaluates every success criterion at levels A and AA for every view in scope, operates every defined user flow with the keyboard, checks the output for screen readers and documents every barrier with its criterion, severity and a solution. Your completed checklist is a useful starting point, because it shows which pages and flows matter to you and where you have already stumbled.
After the fixes, regular accessibility monitoring keeps an eye on the level you have reached. The implementation itself is handled by our accessible web development team if yours does not have the time.
Sources
Related Articles
Accessible Customer Portals: Auditing the Login Area
Automated scans stop at the sign-in form. How a WCAG audit covers the protected area: scope, test accounts, session timeouts and screen reader testing.
Accessibility Audit Cost 2026: Prices, ROI, Funding
What a WCAG 2.2 audit costs in 2026: prices by scope, sampling versus full audit, monitoring, the BFSG fine ceiling, conversion ROI and funding at a glance.
AI-Generated Code: What Accessibility Testing Finds
What accessibility testing finds in AI-generated code: four typical patterns, from div buttons to removed focus outlines, and how testing fits the workflow.