Emirates is committed to making this website accessible to the broadest possible audience, regardless of technology or physical capability. To this end, we are working constantly to improve the overall usability of the site, using Web Content Accessibility Guidelines (WCAG) 2.0 Level AA Success Criteria.
If you have any questions or suggestions regarding the use of this site, please contact us.
Accessibility features on Emirates.com
We have implemented many features on emirates.com to help you navigate the site. Below is a comprehensive list, which we encourage you to read. We have included useful ways to navigate some of the more complex widgets, such as calendar controls, as well as details about areas where we are currently facing challenges. We have worked with several organizations, including the American Foundation for the Blind and the Royal National Institute for the Blind, to test the usability of our site and to enhance and improve the experience for you. We have built emirates.com to WCAG 2.0 Level AA and have created a site that works well with NVDA and Firefox. We recommend using the latest versions of these screen readers. This is our first step and we will be building on it to include better support for other screen readers in the near future.
Skip to content: We have a Skip to Content link at the top of the page before our logo to help you navigate the page.
Images: We have applied descriptive alt tags to all images (and images of text) that provide information and applied null alt tags to all decorative images. In limited places, we have added hidden text around content to eliminate the need for alt tags. We feel that adding this information for screen reader users enables us to deliver a richer experience than an alt tag allows. We have only done this in consultation with our accessibility partners.
Forms: All forms are accessible from the keyboard and have programmatical labels so that you can understand what the form field is. In various places across our booking engine, we are using custom form fields and have worked hard to maintain a standard interaction.
Tables: While we use a large number of tables on the site, any tables that are for presentational purposes have been given a presentation role so that the screen reader doesn't read out column and row information. All data tables have appropriate headers. All complex tables have summaries.
Headings: We have applied headings across the site to break up content appropriately.
Links: We have provided descriptive link names so that you know what links do and can make sense of context. We have applied hidden text to let you know when a link opens a new window/tab.
ARIA Landmarks: We have used these sparingly and generally only use role=”main” around the main content of the page. We have also used role=”complimentary” to help divide content.
Use of ARIA: As we have a dynamic site, we have used various ARIA roles, properties, and states to enhance your experience and help you get the information you need to make informed decisions. We recommend you use a modern browser with a modern screen reader to take advantage of these features.
Controls for keyboard users
Calendar: Once in a calendar, use the up, down, left, and right arrows to move through the dates.
Flexible dates grid: You will see this when you search for a flight using flexible dates. Within the grid, you can use the arrow keys to go to different dates. This will allow you to select dates that suit your schedule and budget.
Terms and Conditions: For keyboard users, there are additional instructions that display on the screen.
ARIA Application Role: We are aware of an issue in which using role=”application” and tabbing out of the object results in the previous link also being read out along with the link that has the focus. This appears to happen in two places:
- In Manage Your Booking, when any options (e.g., excess baggage fees) are disabled, there is a custom tooltip. This tooltip has role=”application” to make it keyboard accessible.
- On content pages where we have a custom calendar, the calendar has role=”application” to make it keyboard accessible. The next element in the tab order is the link “mobile enabled,” but ARIA reads the previous tool tip first (e.g., “flight number help”).
A ticket within the NVDA community(opens an external website) has been created to help resolve this issue.
Check box status: NVDA does not announce the initial change in status (checked/unchecked) on the booking widget that appears when you navigate towards the bottom of the home page. On subsequent changes (checking and unchecking) the status is announced by NVDA.
Forms mode: Within the booking widget, when removing an airport using the Delete option, the focus is returned to the form field but NVDA does not automatically enter forms mode. Therefore, if you start typing immediately, it will not input any information. If you manually enters forms mode, this works as normal.