Accessibility Statement.

1. Our Commitment
The Mokingbrd Collective believes that access to digital information and services is a right, not a privilege. We are committed to maintaining a website that is accessible to the widest possible range of users, including those who use screen readers, keyboard-only navigation, voice control software, screen magnification, switch access devices, or any other assistive technology.
Accessibility is not a compliance exercise for us. We advise clients on accessibility as a professional service. We hold ourselves to the same standard we set for others. Where we fall short (and this statement documents where we currently do), we commit to a specific timeline for resolution.
 

2. Standards We Follow
This website aims to conform to the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA, published by the World Wide Web Consortium (W3C) at www.w3.org/TR/WCAG21.
WCAG 2.1 AA organises accessibility requirements under four principles:
Perceivable. Information and user interface components must be presentable in ways that users can perceive — including via assistive technologies. Content that cannot be perceived by any sense does not exist for that user.
Operable. All functionality must be operable through a keyboard, must give users sufficient time, must not cause seizures, and must help users navigate and find content.
Understandable. Information and the operation of the interface must be understandable. Users must be able to comprehend content and predict how the interface behaves.
Robust. Content must be robust enough to be reliably interpreted by a wide variety of user agents, including current and future assistive technologies. Code quality directly affects accessibility.
We also reference EN 301 549 (the European accessibility standard for ICT) and South Africa's SANS 10266 guidelines where applicable, and we monitor WCAG 2.2 with a view to adopting it as our target standard by end of 2026.


3. Conformance Status
This website is partially conformant with WCAG 2.1 Level AA.
Partially conformant means that some parts of the content do not fully conform to the standard. All known non-conformances are documented in Section 6 (Known Limitations) with their current status and our remediation timeline.
The majority of our pages and features pass WCAG 2.1 AA criteria. The exceptions are three specific components, all of which are being actively addressed and are scheduled for remediation by 30 July 2026.

 
4. WCAG 2.1 AA Conformance Detail
The following documents our assessed status against each applicable WCAG 2.1 Level AA success criterion. Criteria marked Not Applicable are not relevant to the nature of this website's content (for example, criteria relating to audio and video content, which this site does not contain).
1.1.1 Non-text Content — Pass. All non-decorative images have descriptive alt text. Decorative images use empty alt attributes and role="presentation".
1.2.1 Audio-only and Video-only (Prerecorded) — Not Applicable.
1.2.2 Captions (Prerecorded) — Not Applicable.
1.2.3 Audio Description or Media Alternative — Not Applicable.
1.2.4 Captions (Live) — Not Applicable.
1.2.5 Audio Description (Prerecorded) — Not Applicable.
1.3.1 Info and Relationships — Pass. Semantic HTML is used throughout. Headings, lists, tables, and form elements use correct markup. Information conveyed through presentation is also conveyed through structure.
1.3.2 Meaningful Sequence — Pass. The reading and navigation order in the DOM matches the visual presentation.
1.3.3 Sensory Characteristics — Pass. Instructions do not rely solely on sensory characteristics such as shape, colour, size, or location.
1.3.4 Orientation — Pass. Content is not restricted to a single display orientation.
1.3.5 Identify Input Purpose — Pass. Form inputs use appropriate autocomplete attributes.
1.4.1 Use of Colour — Pass. Colour is not used as the sole means of conveying information. All status indicators, error messages, and data visualisations include non-colour identifiers.
1.4.2 Audio Control — Not Applicable.
1.4.3 Contrast (Minimum) — Pass. All body text achieves a minimum contrast ratio of 7:1 against its background. All large text achieves a minimum of 4.5:1. We aim to exceed the AA minimum throughout.
1.4.4 Resize Text — Pass. All text can be resized up to 200% using browser zoom without loss of content or functionality.
1.4.5 Images of Text — Pass. We do not use images of text except in our logo mark, which is treated as a decorative image with appropriate alt text.
1.4.10 Reflow — Partial. See Known Limitations, Issue 2.
1.4.11 Non-text Contrast — Pass. All UI components and graphical objects that convey meaning meet a minimum 3:1 contrast ratio.
1.4.12 Text Spacing — Pass. No content or functionality is lost when line height is set to 1.5 times font size, letter spacing to 0.12 times font size, word spacing to 0.16 times font size, and spacing following paragraphs to 2 times font size.
1.4.13 Content on Hover or Focus — Pass. Hover and focus-triggered content is dismissible, hoverable, and persistent.
2.1.1 Keyboard — Pass. All functionality is operable through keyboard alone. No keyboard traps exist.
2.1.2 No Keyboard Trap — Pass. Keyboard focus is never locked within a component.
2.1.4 Character Key Shortcuts — Not Applicable.
2.2.1 Timing Adjustable — Not Applicable.
2.2.2 Pause, Stop, Hide — Partial. See Known Limitations, Issue 1.
2.3.1 Three Flashes or Below Threshold — Pass. No content flashes more than three times per second.
2.4.1 Bypass Blocks — Pass. A "Skip to main content" link is the first focusable element on every page.
2.4.2 Page Titled — Pass. Every page has a unique, descriptive title that includes both the page name and the site name.
2.4.3 Focus Order — Pass. Focus order follows a logical sequence that preserves meaning and operability.
2.4.4 Link Purpose (In Context) — Pass. Every link's purpose is determinable from its text alone or from its immediate context.
2.4.5 Multiple Ways — Pass. Users can find any page via the navigation menu and via the site search. A sitemap is available.
2.4.6 Headings and Labels — Pass. All headings and form labels are descriptive of their content.
2.4.7 Focus Visible — Pass. All interactive elements display a clearly visible focus indicator with a minimum 3:1 contrast ratio against adjacent colours.
2.5.1 Pointer Gestures — Pass. All functionality that uses multi-point or path-based gestures has a single-pointer alternative.
2.5.2 Pointer Cancellation — Pass. No actions are triggered on the down event; all can be cancelled before completion.
2.5.3 Label in Name — Pass. All interactive elements with visible labels contain the visible label text in their accessible name.
2.5.4 Motion Actuation — Not Applicable.
3.1.1 Language of Page — Pass. The HTML lang attribute is set to "en" on every page.
3.1.2 Language of Parts — Pass. Sections of content in a different language are marked with the appropriate lang attribute.
3.2.1 On Focus — Pass. No context change occurs when a component receives focus.
3.2.2 On Input — Pass. No context change occurs when a form input is changed, without prior notice.
3.2.3 Consistent Navigation — Pass. Navigation is consistent in order and presentation across all pages.
3.2.4 Consistent Identification — Pass. Components with the same function are identified consistently across all pages.
3.3.1 Error Identification — Pass. Form errors are identified in text and programmatically associated with the relevant input.
3.3.2 Labels or Instructions — Pass. All form inputs have visible labels and, where necessary, instructional text.
3.3.3 Error Suggestion — Pass. Where an input error is detected, we provide a specific suggestion for correction where possible.
3.3.4 Error Prevention (Legal, Financial, Data) — Pass. All form submissions are reversible or include a confirmation step before final submission.
4.1.1 Parsing — Pass. HTML is valid and free from parsing errors that would affect assistive technology.
4.1.2 Name, Role, Value — Pass. All UI components have programmatically determinable names, roles, and values. Custom components use appropriate ARIA roles and properties.
4.1.3 Status Messages — Partial. See Known Limitations, Issue 3.


 
5. Accessibility Features Implemented
The following features have been deliberately implemented to support users with disabilities:
Skip navigation link. A "Skip to main content" link is the first focusable element on every page, allowing screen reader and keyboard users to bypass the navigation menu and proceed directly to the page content. It becomes visible on focus.
Full keyboard navigation. Every interactive element — including navigation menus, buttons, forms, tabs, accordions, and links — is fully operable using only a keyboard. Tab navigates forward; Shift+Tab navigates in reverse. Enter and Space activate buttons and links as expected.
Logical focus order. Tab order follows the visual reading order of each page. Focus does not jump unexpectedly between sections.
Visible focus indicators. All interactive elements display a clearly visible focus ring when focused via keyboard. Focus indicators meet a minimum 3:1 contrast ratio against adjacent colours and are clearly distinguishable from the default browser styles.
Semantic HTML structure. We use correct heading hierarchy (h1 through h4), landmark regions (main, nav, header, footer, aside, section), list elements (ul, ol, li), and table markup throughout. Screen reader users can navigate the page structure without reading every word.
Descriptive alt text. Every non-decorative image carries a descriptive alt attribute explaining its content and function. Decorative images use empty alt attributes (alt="") and role="presentation" so that screen readers skip over them.
Colour contrast compliance. All body text meets a minimum 7:1 contrast ratio against its background. All large text (18pt or 14pt bold and above) meets a minimum 4.5:1 ratio. All UI component borders and graphical elements that convey meaning meet a minimum 3:1 ratio.
Colour-independent information. We do not rely on colour alone to convey any information. Status indicators include text labels, icons, or patterns in addition to colour. Error messages use text descriptions, not just red borders.
Responsive and zoom-friendly layout. The site is fully functional at all screen sizes from 320px wide upwards and at browser zoom levels up to 200%. Text and layout reflow without horizontal scrolling (with the exceptions noted in Known Limitations).
Language declaration. The HTML lang="en" attribute is set on every page, enabling screen readers to apply correct pronunciation and language rules.
Reduced motion support. All CSS animations and transitions respect the prefers-reduced-motion media query. Users who have enabled the "reduce motion" preference in their operating system will see static presentations of all animated content, including the specials carousel (which becomes a static grid) and all scroll-triggered animations.
Form accessibility. Every form input has an explicit associated label element. Required fields are identified both visually and via the required attribute. Error messages are programmatically associated with their corresponding inputs using aria-describedby. Success and error states are communicated in text, not colour alone.
ARIA labels on icon-only controls. All buttons and controls that use icons without visible text carry descriptive aria-label attributes, ensuring screen reader users understand the function of each control.
Descriptive page titles. Every page carries a unique title in the format "Page Name — The Mokingbrd Collective", enabling screen reader users to identify the page from the browser tab or window list.
Autocomplete attributes. All form inputs that collect personal information use appropriate HTML autocomplete attribute values, supporting users who rely on autofill and users with cognitive or motor disabilities.


6. Known Limitations
Despite our best efforts, the following accessibility issues are currently known. We document them here in the interest of full transparency. In each case we provide the affected criterion, the nature of the issue, the impact on users, any available workaround, and our committed remediation date.

Issue 1: Scrolling content carousel — WCAG 2.2.2 (Partial)
Affected page: Specials / Featured Content section (main site and Insights page)
Nature of issue: The auto-scrolling carousel that displays featured items moves continuously. While it pauses when a mouse cursor hovers over it, it does not provide a keyboard-accessible mechanism to pause, stop, or hide the motion. Users who cannot use a mouse and who have not enabled the operating system reduced-motion preference have no way to stop the movement.
Impact: Users who find moving content distracting or disorienting; users with attention or cognitive conditions that are affected by peripheral movement; keyboard-only users who cannot use hover to pause.
Current workaround: Users with the prefers-reduced-motion operating system setting enabled will see a static grid layout instead of the carousel — the content is fully accessible in this mode. Users who cannot tolerate the motion are advised to enable this setting in their OS accessibility settings.
Remediation: A visible, keyboard-focusable pause button will be added to the carousel. Estimated completion: 30 July 2026
 
Issue 2: Reflow at 320px viewport width — WCAG 1.4.10 (Partial)
Affected pages: Accessibility Statement (this page) and Privacy Policy — specifically the conformance detail tables.
Nature of issue: The WCAG criteria tables on this page contain multiple columns of data. At a viewport width of 320px, or at browser zoom levels above approximately 250%, the tables require horizontal scrolling to view all columns. The content is wrapped in a scrollable container so no information is lost, but horizontal scrolling is required, which does not meet the reflow criterion.
Impact: Users on very small screens (some feature phones and small mobile devices); users who rely on significant browser zoom levels.
Current workaround: The table is wrapped in a horizontally scrollable container, so all content is accessible by scrolling horizontally within the table area. No information is hidden or truncated.
Remediation: A responsive table pattern will be implemented that transforms into a stacked card layout at narrow viewports. Estimated completion: 30 July 2026.
 
Issue 3: Status message announcements — WCAG 4.1.3 (Partial)
Affected page: Menu tab interface on services and menu pages.
Nature of issue: When a user activates a tab to switch between content panels (for example, switching from "Mains" to "Starters" on the menu), the newly loaded content is not announced via an ARIA live region. Screen reader users may not be immediately aware that the content of the page has changed.
Impact: Screen reader users interacting with the tabbed menu interface.
Current workaround: On tab activation, focus is programmatically moved to the first heading within the newly active panel. Most screen readers will read the heading on focus, giving the user an implicit indication that the content has changed. However, this is not a fully conformant implementation.
Remediation: An ARIA live region with role="status" will be added to announce content panel changes. Estimated completion: 30 July 2026.

 
7. Assistive Technology Compatibility
This website has been tested with the following combinations of assistive technologies and browsers. We aim to maintain compatibility with the current version and the immediately preceding version of each:

• NVDA (current and previous version) with Google Chrome on Windows 11

• NVDA (current version) with Mozilla Firefox on Windows 11

• VoiceOver with Safari on macOS Sonoma (14)

• VoiceOver with Safari on iOS 17

• JAWS 2024 with Google Chrome on Windows 11

• JAWS 2024 with Microsoft Edge on Windows 11

• TalkBack with Google Chrome on Android 14

• Dragon NaturallySpeaking 16 — voice navigation and dictation testing

• ZoomText Fusion 2024 — screen magnification and screen reading

• Windows Magnifier — magnification testing at 200% and 400%

Automated accessibility testing is conducted using axe DevTools and Google Lighthouse as part of our deployment pipeline. Every code deployment triggers an automated accessibility scan; findings above a severity threshold of "serious" block deployment until resolved. Manual expert review is conducted quarterly.


 
8. Third-Party Content
Our website includes content and tools provided by the following third parties. We have selected these providers based in part on their published accessibility commitments, but we cannot guarantee full control over all third-party rendered content:
Google Analytics 4. Analytics tracking script. Not user-facing. No accessibility impact.
For any third-party component on our site that presents an accessibility barrier to you, please contact us. We will either work with the provider to resolve it or provide an equally effective alternative.

 
9. Feedback, Contact, and Reporting
We actively want to know about accessibility barriers on our website. Every report is treated as a priority issue.
Accessibility contact: Email: psoonderjee@themokingbrdcollective.com Office hours: Monday to Sunday, 08:00–17:00 SAST
When contacting us it helps to include: The URL of the page where you encountered the barrier. The assistive technology, browser, and operating system you are using (and their version numbers if possible). A description of what you were trying to do and what happened or didn't happen. Whether you have a preferred alternative method we can offer while the issue is being resolved.
Response time commitment: We will acknowledge your report within 2 business days and provide a resolution or workaround within 10 business days. For critical barriers preventing access to essential content or contact methods, we aim to resolve or provide an alternative within 24 hours.

 
10. Formal Complaints and Enforcement
If you are not satisfied with our response to an accessibility complaint, or if you believe we have failed to meet our legal obligations regarding accessibility, you have recourse through the following channels:
South African Human Rights Commission (SAHRC). The SAHRC handles complaints relating to the right of access to information and equality of access, including digital accessibility under the Promotion of Equality and Prevention of Unfair Discrimination Act (PEPUDA). Website: www.sahrc.org.za
Telephone: +27 11 877 3600
Equality Court. Under PEPUDA, you may bring a complaint to the Equality Court regarding inaccessible digital services that amount to unfair discrimination on the basis of disability.
Information Regulator. Where accessibility barriers relate to the withholding of information you are entitled to access, the Information Regulator may have jurisdiction. Website: www.inforegulator.org.za
We strongly encourage direct contact with us first. Barriers are almost always resolved faster through direct engagement than through formal processes, and we genuinely want to resolve any lapses in accessibility.

 
11. Review and Improvement Schedule
Automated testing: On every code deployment via CI/CD pipeline. Findings of "serious" severity or above block deployment.
Manual expert review: Quarterly. Next due: July 2026.
Full assistive technology audit: Annually with an external accessibility consultant. Next due: November 2026.
Statement review and update: Following any material change to site content, functionality, or our conformance status; and at minimum annually.
Target milestones: Full WCAG 2.1 Level AA conformance — 30 July 2026.
WCAG 2.2 gap analysis completed — 31 October 2026.
WCAG 2.2 Level AA target conformance — 31 December 2026.

 
12. Statement Preparation
This accessibility statement was prepared on 1 April 2065 by The Mokingbrd Collective. It is based on a self-assessment conducted in March 2026 using a combination of automated testing (axe DevTools, Google Lighthouse, WAVE) and manual testing with NVDA, VoiceOver, and keyboard-only navigation. The statement will next be reviewed in July 2026 following the scheduled quarterly manual audit.