Accessibility

Our target

MHAuthority aims to meet or exceed the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. Accessibility is part of the definition of done for every component we build, not a pass performed at the end.

What is implemented

• Keyboard operation throughout. Every interactive control is reachable and operable by keyboard. A skip link is the first focusable element on every page.
• A single, high-contrast focus indicator applied consistently, using :focus-visible so keyboard users always see it.
• Search that works without JavaScript. Filters, sorting, and pagination are real forms and links, so results are available to assistive technology and to anyone on a degraded connection.
• Real disclosure patterns. Navigation menus use aria-expanded and aria-controls, close on Escape, and return focus to their trigger. Nothing depends on hover.
• The photo gallery is fully operable. Thumbnails are a tablist with arrow, Home, and End keys. The full-screen viewer is a modal dialog that traps focus, closes on Escape, and restores focus on exit.
• Forms with associated labels, an error summary with role="alert", and aria-invalid plus aria-describedby on each field that has a problem.
• Status is never conveyed by colour alone. Every listing-status badge carries text, and invalid form fields get a thicker border alongside their message.
• Minimum 44 × 44 pixel targets on interactive controls, per WCAG 2.2 success criterion 2.5.8.
• Reduced-motion support. Animation and smooth scrolling are disabled when your system requests reduced motion.
• Zoom and text resizing work. We do not set maximum-scale, so pinch zoom is available.
• Forced-colours mode is handled, with borders and focus indicators that survive it.
• Alt text we can stand behind. Where a listing supplies a caption we use it. Where it does not, we generate factual alternative text from the address and home type rather than inventing a description of a photograph we cannot see.

What we have not finished testing

This is the part most accessibility statements leave out. Automated checks catch a minority of real barriers, and the following manual testing is still outstanding:

• Full screen-reader passes with NVDA, JAWS, and VoiceOver on the search, listing, and lead-form flows.
• Mobile screen-reader testing with VoiceOver on iOS and TalkBack on Android.
• Verification at 200% and 400% browser zoom across every breakpoint.
• An independent third-party audit.

Until those are complete we are not claiming conformance, we are describing a target and our progress toward it. We would rather you knew that than discovered it.

Known limitations

• Some listing photographs come to us without captions. In those cases our alternative text describes the home and its location but cannot describe what the photograph shows.
• Listing content, including descriptions written by agents, is supplied by third parties and may not follow plain-language or accessibility conventions.

Tell us about a barrier

If something on MHAuthority is difficult or impossible for you to use, we want to hear about it, it is the most useful accessibility feedback we can get. Use our contact form and tell us what you were trying to do, what page you were on, and what assistive technology or settings you use if you are comfortable sharing that.

If you need information from a listing that you cannot access, tell us and we will get it to you in a form you can use.