Accessibility is essential for some, and useful for all. As someone who develops our Air France / KLM’s digital products, there are several important practices that we can follow to ensure that our code creates an accessible and inclusive experience for our visitors.
Perceivable
Ensuring content is perceivable means making sure that all visitors can access and understand the information we present, regardless of how they process or perceive the world.
Text Alternatives
To include as many people as possible, we need to ensure that all non-text content has appropriate alternatives:
- Images: All informative, functional and emotionally rich images must have a descriptive alternative to ensure they are accessible to users of assistive technologies.
- Media: Videos must have accurate captions, and audio content should be accompanied by transcripts. These alternatives ensure that our content is accessible to users who are D/deaf or hard of hearing.
Provide Landmarks
Landmarks help assistive technology users orient themselves and navigate a page effectively.
- Use HTML5 elements such as <nav>, <header>, <main>, and <footer> to define the structure of your page.
- If there are multiple landmarks on a page, give each one a unique and accessible name using aria-label. This helps users quickly identify and navigate to the right section.
Operable
Ensure that all visitors, regardless of their input device, are able to interact with and navigate our content.
Keyboard Navigation
Some people will navigate our products using a keyboard rather than a mouse. To make sure our interfaces are fully operable:
- Focus order: Ensure the focus order of interactive elements (like buttons, links, and form fields) follows a logical, predictable sequence, usually from left to right and top to bottom. This helps users navigate content efficiently.
- Interactive elements: All buttons, links, and other controls must be keyboard-accessible. If custom components are used, ensure they are properly tested and function as expected with a keyboard.
By following these practices, we include a wide range of visitors, including those that may use other input devices, such as a wand, or a switch.
Touch Targets
For users with motor impairments or on mobile devices:
- Ensure touch targets (like buttons and links) are large enough to be easily tapped. The minimum size should be at least 24x24px on web and follow Android and iOS recommendations for mobile apps.
Alternative Interaction Methods
Complex interactions, such as maps or carousels, should provide alternative means of interaction. For example, keyboard users should be able to navigate a map using arrow keys, and content should be accessible without relying on gestures like pinching or dragging.
If this isn't possible, alternative routes must be provided to offer the same information or functionality.
Understandable
Content should be presented in a way that is intuitive and easy to understand for everyone, including people with low literacy, cognitive impairments or those using assistive technology.
Clear Structure and Headings
The structure of a page should be clear and logical, both visually and in the underlying code:
- Use semantic HTML headings to clearly define sections and subsections. Ensure that each page has a single <h1>for the main title, followed by <h2>, <h3>, etc., for subsections. Skipping heading levels can confuse users who rely on screen readers to navigate content.
- Work with your designer to keep content organised, with plenty of white space to make it easier to scan and read.
Meaningful Labels for Interactive Elements
All interactive elements should have clear and descriptive labels that explain their purpose. For example:
- If an accessible name is not already present (eg a plain text label), then use aria-label, aria-labelledby, or visually hidden text (such as with sr-only CSS) to ensure that buttons, links, and form inputs are easily identifiable to assistive technology users.
- Collaborate with your UX writer to determine if labels like "Select" or "Read more" provide enough clarity. Encourage the use of context-specific links, such as ‘Baggage policy’ If repeated button labels are necessary, provide additional context using aria-label, aria-labelledby, or sr-only CSS.
Form Validation
Forms should include accessible error handling to help users easily identify and correct mistakes:
- Use clear error messages and link them to relevant form fields using aria-describedby.
- Highlight invalid fields using more than just colour to ensure users know where to focus and what to correct.
Robust
Ensuring our code is robust means making sure it works well across all devices, browsers, and assistive technologies, both now and in the future.
Use of ARIA and HTML5
Where possible, use native HTML elements, as they are inherently accessible. If native elements aren’t available:
- Use ARIA (Accessible Rich Internet Applications) attributes sparingly and appropriately to enhance the accessibility of custom widgets and controls. For example:
- Use aria-expanded to indicate whether collapsible content is open or closed.
- Use aria-live="polite" to notify users of dynamic updates that have been added to the screen.
- Reserve aria-live="assertive" for critical updates that need immediate attention.
- Follow ARIA best practices: The first rule of ARIA is to not use it if there’s a native HTML element that can achieve the same purpose.
Respecting User Preferences
Many users customise their device settings to suit their specific needs. These preferences can include larger font sizes, high-contrast themes, or reduced motion. Respecting these settings ensures a more inclusive experience:
- Responsive to user settings: Use CSS media queries to detect and adapt to user preferences such as reduced motion (prefers-reduced-motion) or high contrast modes.
- Ensure users can zoom the page up to 400% without losing functionality or breaking layouts. This helps users with low vision who rely on screen magnification.
Testing for Accessibility
Ensuring accessibility in practice requires regular testing as part of your workflow. Here are some checks that every engineer can follow:
Keyboard Navigation
Unplug your mouse and use only your keyboard to navigate through your interface:
- Can you access all interactive content (links, buttons, forms) using the keyboard?
- Is there a visible focus indicator showing where you are on the page?
- Ensure there are no keyboard traps where you can get stuck.
Screen Reader Testing
Familiarise yourself with screen readers to understand how users with visual impairments might navigate your content. Test your work with a combination of common tools, such as:
- NVDA with Chrome
- NVDA with Edge
- VoiceOver with Safari
Screen readers will help highlight any gaps in your semantic structure and interaction patterns that may not be immediately apparent.
Conclusion
As engineers, we play a pivotal role in making Air France / KLM’s digital experiences accessible to all users.
Accessibility is not a one-time task but an ongoing process of learning, testing, and improving. Keep accessibility at the forefront of every project, and continuously refine your skills by familiarising yourself with the WCAG standards and engaging with the topic.