Two ways of saying the same thing
A website is judged by whoever happens to be using it. That person might be holding a phone in one hand on a crowded train. They might have a cracked screen, a slow connection, or poor eyesight. They might be navigating with a keyboard, a switch device or a screen reader because they cannot use a mouse or see the display. None of these visitors are unusual, and a good evaluation treats them as normal.
Mobile friendliness and accessibility are often discussed separately, but they share a goal: the page should work for the person in front of it, not only for the designer’s laptop. Many fixes help both groups at once. Larger text and clear spacing help a thumb and tired eyes. A properly labeled form field helps a phone keyboard and a screen reader.
Why small screens change the judgment
Most sites receive a large share of visits from phones, and for many sites phones are the majority. Search engines have also, for years, generally evaluated the mobile version of a page when deciding how to understand it. The exact approach changes over time, but the practical lesson is stable: if the phone version is weaker than the desktop version, the phone version is the one that matters.
A small screen creates specific constraints:
- Little horizontal room. Wide tables, fixed-width images and long unbroken strings can force sideways scrolling.
- Touch instead of a pointer. Fingers are less precise than a mouse cursor, and there is no hover state to reveal hidden menus.
- Variable conditions. Glare, motion, interruptions and weaker connections are common.
- Less patience for obstacles. A large overlay that is mildly annoying on a desktop can cover most of a phone screen.
When you review a page, load it on a phone first, before you look at it on a large monitor. The difference in impression is often immediate.
Why varied abilities change the judgment
Accessibility covers a wide range of situations: low vision, color blindness, hearing loss, motor limitations, cognitive and learning differences, and temporary conditions such as a broken wrist or bright sunlight. Published accessibility guidelines organize their advice around four ideas: content should be perceivable, operable, understandable and robust enough to work with different technologies.
In practice, that translates into questions like these:
- Can someone who cannot see an image still get its meaning?
- Is text readable against its background?
- Can every link, button and form be reached and used without a mouse?
- Are errors and instructions written clearly enough to act on?
- Does the page still make sense when text is enlarged?
Accessibility also overlaps with search. A page with clear headings, descriptive link text and described images is easier for software to interpret, whether that software is a screen reader or a crawler. That is not a promise that accessibility work changes rankings; it is an observation that clear structure tends to be useful to machines and people alike. Related structural habits appear in heading structure and plain language, both of which pay off here.
A basic checklist that covers both
You do not need specialized training for a first pass. Work through these areas and note what fails:
- Viewport and layout. Does the page fit the screen width without sideways scrolling? A responsive layout adapts to the screen, and the trade-offs against separate mobile pages are worth understanding before a redesign.
- Text size and spacing. Can you read body text without zooming? Are links and buttons large and spaced enough to tap accurately?
- Contrast. Is text clearly distinguishable from its background, including on buttons, placeholders and text over images?
- Images. Do meaningful images have short descriptions, and do decorative ones avoid adding noise?
- Keyboard use. Can you reach everything with the Tab key, see where you are, and operate menus and forms?
- Forms. Are fields labeled, sized for thumbs, and paired with errors that explain the problem?
- Overlays. Do pop-ups, banners or cookie notices cover the content on a small screen?
- Speed. Does the page load acceptably on a weaker connection? Core web vitals and page speed are the usual way to discuss this.
Each item has its own deeper treatment in this section of the guide. The point of a first pass is to find the obvious barriers, not to certify anything.
What to expect from tools and from yourself
Automated checkers can detect some problems, such as missing image descriptions, certain contrast failures and empty form labels. They typically cannot judge whether a description is useful, whether a focus order makes sense, or whether an error message is understandable. Treat automated results as a starting list and use your own eyes, a keyboard and a real phone to fill the gaps. If you are building a wider audit, these checks fit naturally into a website evaluation checklist as one section rather than a separate project.
It is also fair to be realistic. A small site will rarely be perfect, and perfection is not the usual benchmark. A useful goal is to remove the barriers that stop people from reading, finding information or completing a task, then keep an eye on new ones as pages change.
Where to put your effort first
If time is limited, prioritize by how many people a problem affects and how badly it blocks them. A form that cannot be completed on a phone, text that cannot be read, or a menu that cannot be reached with a keyboard will stop visitors outright. Minor visual inconsistencies rarely do. Fix blockers first, then annoyances, then polish, which is the same logic described in fix prioritization for any audit.
Finally, revisit the checks after significant changes. New templates, plugins, banners and redesigns are common sources of new barriers, and a quick pass on a phone and with a keyboard after each one catches most of them. Results will vary by audience and site, and nothing here guarantees a particular outcome in search or in conversions, but a page that more people can actually use is a reasonable thing to aim for.