Skip to main content
logo-mid-2

Accessibility

Accessibility Statement

Our ongoing commitment to making midremodeling.com usable for every visitor — including those who use a screen reader, keyboard, or other assistive technology.

Last reviewed: May 17, 2026

Our commitment

Master in Design Inc. is committed to ensuring that midremodeling.com is accessible to everyone in our community — including visitors who use assistive technology such as screen readers, screen magnifiers, voice-control software, or keyboard-only navigation. Accessibility is part of how we serve homeowners across Tarzana, Encino, Woodland Hills, Sherman Oaks, Studio City, Calabasas, Hidden Hills, and the greater Los Angeles area.

Conformance status

This site aims to conform to Web Content Accessibility Guidelines (WCAG) 2.1 Level AA, the international standard published by the World Wide Web Consortium (W3C). WCAG defines how to make web content more accessible to people with disabilities including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.

An independent automated audit (axe‑core) of representative pages currently reports zero critical violations. We continue to test with manual keyboard navigation and screen-reader walkthroughs.

What we’ve done

Navigation and page structure

  • Single <main> landmark on every page. Assistive technology can jump straight to the page content without re-traversing the header on every navigation.
  • Skip-to-content link. The first keyboard stop on every page is a “Skip to main content” link that bypasses the header and goes directly to the main region.
  • Distinct, labeled navigation landmarks. The desktop menu, the mobile dropdown menu, and each footer column carry unique aria-label values so screen-reader users can list and jump between them without confusion.
  • aria-current=“page” on the active nav item. Screen readers announce which page you are currently on as you navigate the menu.
  • One H1 per page, logical heading hierarchy. No skipped levels (H2 → H4), so the page outline read by assistive technology matches the visual structure.
  • Semantic <header>, <main>, <nav>, <footer> regions. Generic <div> containers were replaced or augmented with the correct HTML5 landmark elements.

Keyboard support

  • Visible focus indicator on every interactive element. Links, buttons, form fields, the FAQ accordions, the before/after slider handle, and the mobile menu toggle all show a clear 2px gold outline when reached with the keyboard. Mouse users see no outline (we use :focus-visible rather than :focus) so the visual design is preserved for pointer users.
  • No keyboard traps. Tab moves forward through every interactive control, Shift+Tab moves back, Escape closes the mobile menu, Enter and Space activate buttons.
  • Logical tab order. Focus moves in the same order the page reads visually — left to right, top to bottom — with no tabindex shortcuts that would jump out of order.
  • Before/after comparison slider is fully keyboard operable. Tab to focus the handle, then use Left/Right arrows to nudge by 4%, Shift+arrows for 10%, Home for fully “before”, End for fully “after”.

Screen-reader support

  • Star ratings on testimonials carry an aria-label. Screen readers announce “Rated 5 out of 5 stars” once, instead of reading the five “black star” glyphs individually.
  • Before/after slider announces its position. The slider handle uses the WAI-ARIA role=“slider” pattern with aria-valuenow and aria-valuetext so screen readers report “47 percent — showing both” (or “fully before”, “fully after”) as the user moves the handle.
  • FAQ accordions announce open/closed state. Each <details> element mirrors its open/closed status to aria-expanded on the question summary, so screen readers say “collapsed” or “expanded”.
  • Form errors announced as alerts. When you submit a form with a missing or invalid field, the error message carries role=“alert” so screen readers read it immediately without needing to navigate to it.
  • Decorative glyphs hidden from screen readers. Breadcrumb separators (/), blog meta dots (·), the testimonial quote glyph, decorative icons, and inline SVGs without text alternatives all carry aria-hidden=“true” so they don’t clutter the reading order.
  • Blog post dates are machine-readable. Each date uses the semantic <time datetime=”YYYY-MM-DD”> element so assistive technology, search engines, and reader-mode tools can parse it.
  • Card-link de-duplication. When a card had two links to the same article (image link + headline link), the image link is hidden from screen readers and keyboard so the article is announced once, not twice.

Forms

  • Programmatic labels on every input. Each text field, email, phone, and message input has a properly associated <label> so screen readers announce the field name when focused.
  • aria-required=“true” on required fields. Screen readers announce “required” alongside the field name before you type.
  • autocomplete tokens (name, email, tel). Password managers, adaptive keyboards, and one-tap autofill on mobile work correctly on every form.
  • Hidden spam-prevention fields are also hidden from assistive technology. Honeypot fields carry aria-hidden=“true” and tabindex=“-1” so they never trap keyboard or screen-reader users.

Images and media

  • Descriptive alt text on every project gallery image. Each photo describes the room type, project title, and location (e.g. “Bathroom Gallery — Master in Design portfolio, Tarzana CA”) so screen-reader users get the same context sighted users get from looking at the image.
  • Before/after image alts indicate which state. The “before” and “after” photos in each comparison are labeled accordingly so screen-reader users understand which is which without seeing the slider.
  • Lightbox triggers have aria-label. Clicking a gallery image opens a larger view; the trigger announces “View larger image: [photo description]” rather than just “link”.
  • Decorative SVG icons hidden from assistive tech. Brand-icon SVGs in the footer (Facebook, Yelp, etc.) carry aria-hidden because the parent link already carries an aria-label — no double announcement.

Motion, contrast, and user preferences

  • prefers-reduced-motion respected. If you have “reduce motion” enabled in macOS, iOS, Windows, or Android, the before/after slider’s introduction animation is skipped and CSS transitions are disabled. The page is still fully usable.
  • Text remains readable at 200% browser zoom. No content gets clipped or hidden when zooming in for low-vision users.
  • Color contrast targeted to WCAG AA. Body text on white, headings on cream, button text on warm-gold — all primary text combinations meet the 4.5:1 contrast threshold (one carry-over edge case is noted under “Known limitations” below).
  • No reliance on color alone for meaning. Form errors are announced with text and ARIA, not just a red border; required-field state is in aria-required, not just a color cue.

Standards and ongoing testing

  • Automated audits. We run axe-core (the industry-standard accessibility testing engine) against representative pages on every plugin release. Current baseline: zero critical violations across the home page, services, before/after gallery, testimonials, blog index, and contact / free-estimate forms.
  • Manual keyboard walkthroughs. Every page is traversed with the keyboard only after each design change.
  • Manual screen-reader testing. We test with VoiceOver on macOS and TalkBack on Android.
  • Semantic HTML over ARIA where possible. We use native <button>, <nav>, <details>, <time> elements rather than adding ARIA roles to generic <div>s — this is more robust across the long tail of assistive-technology software.
  • No accessibility overlay or widget. We removed the previous floating accessibility widget. Overlays only adjust what sighted mouse users see — they do not help screen-reader, keyboard-only, voice-control, or switch users. Instead we fix the underlying HTML so every assistive technology gets a properly built page from the start.

Browser and assistive-technology compatibility

The site is designed to work with current versions of:

  • Browsers: Chrome, Edge, Firefox, and Safari on desktop and mobile.
  • Screen readers: VoiceOver (macOS, iOS), TalkBack (Android), NVDA and JAWS (Windows).
  • Other tools: Standard browser zoom up to 200%, OS-level high-contrast modes, and reduced-motion preferences.

Tell us when something doesn’t work

If you encounter an accessibility barrier on midremodeling.com — a page you can’t reach, a form you can’t complete, an image without a description, or anything that gets in the way — please let us know so we can fix it.

We aim to respond within five business days. Please include the page URL and a brief description of the issue so we can reproduce it quickly.

Enforcement and your rights

Master in Design Inc. is committed to providing equal access to our website. If you would like to make a formal complaint, you may contact the U.S. Department of Justice ADA Information Line at 1-800-514-0301 or visit ADA.gov.

Standards referenced

  • WCAG 2.1 Level AA (W3C Recommendation, June 2018)
  • Americans with Disabilities Act (ADA) Title III
  • Section 508 of the Rehabilitation Act
  • California Unruh Civil Rights Act

Found a problem? Tell us.

Contact Us