Skip to main content

ISO 30071-1: Digital Accessibility

The ISO/IEC 30071-1 standard provides requirements and recommendations for an organization to manage digital accessibility. It is a process-focused standard that helps embed accessibility into the entire product lifecycle. A key objective at Omnicom is to ensure the delivery of secure, accessible, and high-quality systems and software, making this standard a cornerstone of our development philosophy.

Understanding ISO 30071-1​

Unlike technical standards such as the Web Content Accessibility Guidelines (WCAG), which define what makes a product accessible, ISO 30071-1 defines the organizational processes and policies for how to achieve, maintain, and improve accessibility consistently. It ensures that accessibility is not an afterthought or a one-time fix, but a fundamental part of business as usual.

The standard helps organizations to:

  • Establish a formal accessibility policy.
  • Assign clear roles and responsibilities for accessibility.
  • Integrate accessibility considerations into all relevant processes, including design, development, and testing.
  • Provide necessary training and resources to personnel.
  • Continuously monitor and improve accessibility practices.

ISO 30071-1 for Osborn Developers: A Practical Guide​

For developers on the Osborn project, your role is to translate the organization's commitment to accessibility into tangible, functional, and robust code in our React frontend.

Required Knowledge​

Personnel involved in solution architecture, design, and development for the Osborn frontend must have knowledge of this standard and, more critically, the technical guidelines it points to, such as WCAG.

Key Developer Responsibilities: Implementing WCAG in React​

The core of a developer's responsibility is the technical implementation of accessibility guidelines. For the Osborn project, this means applying the WCAG POUR principles to our Next.js/React application.

  1. Perceivable:

    • Developer Action: Always provide alt props for images. Use semantic HTML5 elements (<nav>, <main>, etc.) in our React components. Ensure sufficient color contrast, which can be checked using browser dev tools.

  2. Operable:

    • Developer Action: Ensure all interactive components, especially those from the shadcn/ui library, are fully keyboard-navigable. Manage focus correctly in modals and other dynamic components.

  3. Understandable:

    • Developer Action: Use clear and simple language in all UI text. Use <label> elements for all form inputs to ensure they are correctly associated with their controls.

  4. Robust:

    • Developer Action: Write valid JSX and use ARIA (Accessible Rich Internet Applications) attributes correctly to enhance the accessibility of complex components. Our component library, shadcn/ui, is chosen partly for its strong foundation in accessibility and use of ARIA roles.

Integration with the Osborn SDLC​

Accessibility is integrated into every phase of Osborn's SDLC.

  • Requirements Analysis:
    • State the required level of accessibility conformance (e.g., WCAG 2.1 Level AA) in the Jira task.
  • Architecture and Design Phase:
    • Choose component libraries like shadcn/ui that have strong accessibility support.
  • Development Phase:
    • Write semantic JSX and use ARIA where appropriate.
    • Use automated accessibility checking tools like eslint-plugin-jsx-a11y in the local development environment and in the Bitbucket CI/CD pipeline.
  • Testing Phase:
    • Validate compliance with accessibility standards.
    • Perform manual testing, including keyboard navigation and screen reader testing (e.g., VoiceOver, NVDA).
    • Use Storybook to test components in isolation and verify their accessibility properties.
  • Operations/Maintenance:
    • Regularly audit the live application to catch any accessibility regressions.