Issues:
Report for 8 selected Sunweb pages

(Issues only)

Scope of the evaluation

Detailed audit results

1. Perceivable

1.1 Text Alternatives

1.1.1 Non-text Content (Level A)

Information about success criterion 1.1.1 Non-text Content

Finding 1: React / B-variant: The Sunweb logo in the header of each page has the accessible text "Sunweb". The fact that this is a logo carries important information, this signifies that this is a webpage from the Sunweb organization. Add the word "logo" to the alt text. The logo links to the homepage, it is suggested to add the link target to the alt text in order to also conform to 2.4.4.
Non-React: The Sunweb logo in the header of each page is a SVG without accessible text. A logo carries important information and can not be considered decorative. Give informative SVG images an attribute role="img" for browsers to present them as an image and add a text alternative by means of adding a title-element as first child-element. Make sure the present link target "home pagina" remains in order to conform to 2.4.4.

Finding 2: React / B-variant: The header of each page includes icons, not all include a text alternative such as the globe and a magnifying glass. Therefore the buttons they represent have no accessible name, see 4.2.1. Give informative SVG images an attribute role="img" for browsers to present them as an image and add a text alternative by means of adding a title-element as first child-element.
Non-React: In the header of each page there are icons of a globe and a magnifying glass. These images carry meaning but have no text alternative. Therefore the buttons they represent have no accessible name, see 4.2.1. Give icons with meaning always an accessible text, for example by placing them as img with an alt attribute in the html.

Finding 3: React / B-variant: The footer of each page includes social media icons without text alternatives. Therefore the buttons they represent have no accessible name, see 4.2.1. Give informative SVG images an attribute role="img" for browsers to present them as an image and add a text alternative by means of adding a title-element as first child-element.
Non-React: The footer of each page includes social media icons without text alternatives. Therefore the buttons they represent have no accessible name, see 4.2.1. Give icons with meaning always an accessible text, for example by placing them as img with an alt attribute in the html.

Finding 4: React / B-variant: The header of each page *includes an icon with a heart and a number which links to a "favorites" page. Visually the purpose of the link is clear, but assistive technology only displays the number. Add a link tekst only for software. This can be done for example with an aria-label.
Non-React: identical issue.

Finding 5: React / B-variant: The BE/NL search result page contains images with visual text labels such as "LAST MINUTE". This is the same on the other language search pages, such as "AFBUDSREJSER" on the DK search result page. These images have no alt attributes. In many cases supportive software will display the filename of the image. Add an alt attribute that describes the image. It's better not to use an textual image, see 1.4.5.
Non-React: identical issue.

Finding 6: React / B-variant: not present.
Non-React: The BE/NL property specific search result page features the modal "Gun jezelf het voordeel van vakantie" which can appear without warning. The modal consists of an image with text. The text is not available for supportive software and the image has no text alternative. All information in the image is lost to blind visitors. Give the image a text alternative that contains all text and visual information in the image, or add the text as html text on the page to conform 1.4.5.
Note: This modal is discussed under various criteria in this report. As a summary, also keep in mind that the modal must be keyboard accessible, it has a correct place in the focus sequence (focus remains in the modal till the user has closed it) and it's presence is announced by screenreaders upon appearance.

1.2 Time-based Media

1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A)

Information about success criterion 1.2.3 Audio Description or Media Alternative (Prerecorded)

Finding 7: React / B-variant: on the property-specific pages, the image carousel may contain embedded YouTube videos. When it contains no voice but only music, blind visitors don't know what is shown in the video. Add a media alternative or an audio description. The text in the page can be considered as media alternative, but this has to be announced. Add for example a text to the title of the iframe with the video "All information in the video is available in the text on this page". However, this is not sufficient for 1.2.5.
Non-React: identical issue.

1.2.5 Audio Description (Prerecorded) (Level AA)

Information about success criterion 1.2.5 Audio Description (Prerecorded)

Finding 8: React / B-variant: on the property-specific pages, the image carousel may contain embedded YouTube videos. When it contains no voice but only music, blind visitors don't know what is shown in the video. Add a media alternative or an audio description. The text in the page can be considered as media alternative, but this has to be announced. Add for example a text to the title of the iframe with the video "All information in the video is available in the text on this page". However, this is not sufficient for 1.2.5.
Non-React: identical issue.

1.3 Adaptable

1.3.1 Info and Relationships (Level A)

Information about success criterion 1.3.1 Info and Relationships

Finding 9: React / B-variant: upon use of the search field in the header, a selection of results appear under various visual headings. These headings are not marked as such in HTML. There are various solutions to this, from placing them in H-elements to changing the structure of the search results. The result should however be that accessibility aids can identify/differentiate the categories and the underlying links to the user.
Non-React: identical issue.

Finding 10: React / B-variant: many pages feature numbered navigation, such as the "Search" and "Search results". The accessible names of the buttons are "1", "2", "3" etc. For sighted visitors it's obvious that these are page numbers, however for blind visitors it's not clear that these links point to other pages with search results. Add the word "page" to the accessible name of these buttons.
Non-React: identical issue.

Finding 11: React / B-variant: the footer of each page contains an img element "Travelife" with the alternative text "sustainablity". It is nested directly in an unordered list which may only contain list elements, as it cannot be described by assistive technology in it's current form. Put the img element inside a list item.
Non-React: identical issue.

1.4 Distinguishable

1.4.1 Use of Color (Level A)

Information about success criterion 1.4.1 Use of Color

Finding 12: React / B-variant: many pages feature numbered navigation, such as the "Search" and "Search results" pages. A darker hue around a page number indicates the current page. Visually impaired or color blind visitors might miss this information. Use an other indication apart from color contrast, for example an outline, or make sure the difference in color has a ratio larger than 3:1 in order to meet this criterium.
Non-React: identical issue.

1.4.3 Contrast (Minimum) (Level AA)

Information about success criterion 1.4.3 Contrast (Minimum)

Finding 13: React / B-variant: the "Search results" page features red text (HEX #FF333F) on white background, for example the crossed out price and "Lees meer" (BE/NL page). The contrast of these texts is too low, color blind visitors or visitors with impaired vision might not be able to read them. The contrast ratio is 3,6:1 where it should be at least 4,5:1. The white text "Bekijk prijzen" on the same red background has the identical contrast ratio. On the same pages the red percentage on the pink background (HEX #FACAC9) next to the button "Bekijk prijzen" has a too low contrast ratio of 2,9:1.
Non-React: identical issue.

Finding 14: React / B-variant: the "Search results" page features text in different shades of grey on white or light grey backgrounds that do not meet color contrast requirements. For example on the page the text "### Beoordelingen" or "### ervaringen" (BE/NL page) (HEX #837868) on a white background has a contrast ratio of 4,3:1 where this should be at least 4,5:1. On both pages the text "Wees er snel bij!" (HEX #837868) on beige (HEX #F3EFEB) has a contrast ratio of 3,8:1. Make sure all texts have enough contrast in order to be readable by everyone.
Non-React: identical issue.

Finding 15: React / B-variant: the "Search results" page features the white text "Selections" on an orange background (HEX #F66E20) that does not meet the color contrast requirements. The contrast ratio is 2,9:1 where it should be at least 4,5:1.
Non-React: identical issue.

1.4.5 Images of Text (Level AA)

Information about success criterion 1.4.5 Images of Text

Finding 16: React / B-variant: not present.
Non-React: The BE/NL property specific search result page features the modal "Gun jezelf het voordeel van vakantie" which can appear without warning. The modal consists of an image with text. Visitors with impaired vision can not adapt this text to their needs. Add the text in the image also as html text in the page in order to pass this criterium.

1.4.11 Non-text Contrast (Level AA)

Information about success criterion 1.4.11 Non-text Contrast

Finding 17: React / B-variant: on the property-specific pages, yellow stars (HEX #F4BE15) indicate the rating. The contrast of these stars with the white background is too low. The contrast ratio is 1.7:1 where this should be at least 3:1. (Note they are beige grey on the "search results" pages where they do meet the standards. Should the yellow color be preferred, a dark outline would also solve the issue at hand).
Non-React: identical issue.

1.4.12 Text Spacing (Level AA)

Information about success criterion 1.4.12 Text Spacing

Finding 18: React / B-variant: "search results" pages feature a carrousel of various properties, where text content is placed on a white card. If text spacing is used in accordance to the values set by this criterium, text may appear under the card and on the background image. In some cases the contrast between the black text and the image is too low. Good reflow of the card would solve this issue. (This issue also covers criteria 1.1.1 and 1.4.10 but is only mentioned here for efficiency purposes).
Non-React: identical issue.

2. Operable

2.1 Keyboard Accessible

2.1.1 Keyboard (Level A)

Information about success criterion 2.1.1 Keyboard

Finding 19: React / B-variant: the header on each features a profile button opening a dropdown menu ("mijn Sunweb" on the BE/NL page). The link "Inloggen" and "Maak een account aan" do not get keyboard focus and therefore they cannot be activated. Make sure all interactive elements can be operated by means of the keyboard.
Non-React: identical issue.

Finding 20: React / B-variant: the "search results" pages feature a slider for price adjustments. The slider can be controlled by means of the keyboard (arrow keys) although it updates on every keystroke. Setting a price range means having to re-adjust focus for each keystroke, which is a needlessly difficult activity. Mouse users on the other hand can drag and drop with ease. Make sure there is a mechanism to enter a price range for keyboard users, perhaps only appearing upon keyboard focus as skiplinks do.
Non-React: identical issue.

Finding 21: React / B-variant: not present.
Non-React: on property-specific search result pages, images are placed in a slider. Keyboard navigation requires one to tab through all of the images before continuing on the page. In case one opts to use such a slider, make sure a pause button is available. See the React / B-variant page for a good alternative.

2.1.4 Character Key Shortcuts (Level A)

Information about success criterion 2.1.4 Character Key Shortcuts

Finding 22: React / B-variant: on the property-specific pages, the image carousel may contain embedded YouTube videos. This video player uses one key functionality, for example "f" for fullscreen and "m" for mute. This functionality can cause problems for visitors using speech software because they rely on one key commands for website navigation. Solve this by adding the "disablekb=1" command to the embedcode to disable this functionality.
Non-React: identical issue.

2.4 Navigable

2.4.1 Bypass Blocks (Level A)

Information about success criterion 2.4.1 Bypass Blocks

Finding 23: React / B-variant: each page lacks a mechanism to avoid repetitive content, for example the header, and the search filters on "search results" pages. Visitors that navigate the website by means of the keyboard have to click past the same interactive elements on each page before they get to the main content. This can be solved by adding a link tot he page (a skiplink) that moves the focus to the first unique content of a page. This link has to be the first link on the page. It can be hidden for all visitors and only shown when it gets keyboard focus. Multiple skiplinks may be used.
Non-React: identical issue.

2.4.3 Focus Order (Level A)

Information about success criterion 2.4.3 Focus Order

Finding 24: React / B-variant: upon use of the search field in the header, a selection of results appear under various visual headings, followed by a button to view more results of that specific category ("Meer bekijken" in BE/NL). Upon keyboard activation of the button and continued navigation by means of the tab key, the next category receives focus instead of the first newly added search result. Place these new results in the tab order before the next category.
Non-React: identical issue.

Finding 25: React / B-variant: the header on each features a profile button opening a dropdown menu ("mijn Sunweb" on the BE/NL page). When that happens the tab key is no longer active because the element with role="menu" now contains a tabindex=0 attribute making it non-focusable and the nav, main and footer elements are hidden for assistive software by means of an aria-hidden attribute. Visitors relying on navigation by means of the keyboard have only one option to continue and that's the escape key. Make sure the process has a logical tab order and page navigation is not disrupted.
Non-React: identical issue.

Finding 26: React / B-variant: not present.
Non-React: the BE/NL property specific search result page features the modal "Gun jezelf het voordeel van vakantie" which can appear without warning. The modal blocks the view of part of the page behind it but keyboard focus is still on this page and can be on links that are not visible behind the modal window. When a modal blocks part of a page keyboard focus should be only on elements that are inside this modal until it is closed. Do not give keyboard focus to the underlying page.

Finding 27: React / B-variant: the BE/NL property specific search result page features a menu with 6 items underneath the property name ("Algemeen" till "Omgeving"). These items do not fall in the focus order and are therefore skipped by keyboard navigators. Make sure they receive focus as on the non-react variant pages.
Non-React: no issue.

Finding 28: React / B-variant: issue solved.
Non-React: the NL/BE property-specific search result page feature various dropdown elements under the header "Kamertypes". The images within these dropdown menus are focusable even when the menu's are closed. Make sure elements that are not visible don't get keyboard focus.

2.4.4 Link Purpose (In Context) (Level A)

Information about success criterion 2.4.4 Link Purpose (In Context)

Finding 29: React / B-variant: issue solved.
Non-React: The logo of Sunweb in the header of each page is a link to the homepage, but the accessible name of the image is "Sunweb". Add the linktarget, for example by adding it to the alt text.

Finding 30: React / B-variant: the first time a visitor visits the website on the BE/NL version, a cookie warning appears. The Sunweb logo is a link to https://www.cookieinfo.net/. This link target does not correspond with the text "Sunweb". Also the link does not have an accessible name, so for blind visitors it is not clear what the target of the link is. Give the link a proper visual text that describes the target and that's also accessible.
Non-React: identical issue.

Finding 31: React / B-variant: the first time a visitor visits the website on the BE/NL version, a cookie warning appears. In the modal that opens with the button "Beheren" there are a number of triangular dropdown options that all have the same accessible link tekst "Details". For blind visitors it is not clear which details will be shown. Add for example the text of the label of the checkbox to the accessible link text.
Non-React: identical issue.

2.4.7 Focus Visible (Level AA)

Information about success criterion 2.4.7 Focus Visible

Finding 32: React / B-variant: issue solved.
Non-React: the BE/NL property specific search result page features various room types under the header "Kamertypes". These dropdown elements do not feature a focus border. Make sure each element that has keyboard focus has one for good visible indication.

2.5 Input Modalities

2.5.2 Pointer Cancellation (Level A)

Information about success criterion 2.5.2 Pointer Cancellation

Finding 33: React / B-variant:
the "search results" pages contain a filter menu that features a range slider that allows one to enter a minimum and maximum price. When clicking on one point on the slider that indicator will move towards the mouse pointer. It's not possible to stop or cancel this motion or undo the change in price. Do not use a Down-Event in order to comply with this criterium.
Non-react: identical issue.

4. Robust

4.1 Compatible

4.1.2 Name, Role, Value (Level A)

Information about success criterion 4.1.2 Name, Role, Value

Finding 34: React / B-variant: the first time a visitor visits the website on the BE/NL version, a cookie warning appears. In the modal that opens with the button "Beheren" the button that shows the previous page has no accessible name. Blind visitors do not know the purpose of the button. Make sure every interactive element has an accessible name.
Non-react: identical issue.

Finding 35: React / B-variant: the first time a visitor visits the website on the BE/NL version, a cookie warning appears. In the modal that opens with the button "Beheren" there are a number of links with the accessible text "Details" that open or close a block with more information. Sighted visitors can see if a block of information is folded or unfolded. Blind or visually impaired visitors that rely on screen reading software miss the status and don't know whether this information is available or not. Add the status to the code by means of aria-expanded or a similar technique.
Non-react: identical issue.

Finding 36: React / B-variant: the header of each page contains buttons with no text alternatives, only icons: a globe and a magnifying glass. These buttons have no accessible name. Blind visitors don't know what the buttons do. Make sure every interactive element has an accessible name. Also see 1.1.1.
The same problem appears more often on website, for example all buttons with a heart icon that add a destination to favourites an the buttons with an "i" that provide extra information have no accessible name.
Non-react: identical issue.

Finding 37: React / B-variant: on the property-specific search result page underneath the header "Kamertypes" there are a number of room options that open as pop-ups. The button with a downward/upward arrow has no accessible name, only that fact it is a button will be announced by accessibility aids. Blind visitors don't know the purpose of the button.
Non-react: a similar issue is found with the same room descriptions which are featured in dropdown elements here. While sighted visitors can see if the folded or unfolded, blind or visually impaired visitors rely on accessibility aids to convey this status. Add the status to the code by means of aria-expanded or a similar technique.

Finding 38: React / B-variant: various pages feature numbered navigation, such as the "Search" and "Search results" pages. The buttons with arrows to go to the previous or next page have no accessible name. Blind visitors don't know what the buttons do. Give each interactive element an accessible name.
Non-react: identical issue.

Finding 39: React / B-variant: each page features a search option under the header with 4 buttons that open more options ("Wanneer", "Hoelang" etc. on the BE/NL version). The div element that encloses the button has an aria-expanded attribute but this attribute can only be added to interactive elements. Supportive software can not determine whether the options are available or not. This might be solved by moving the aria-expanded attribute to the button inside the div.
Non-react: identical issue.

Finding 40: React / B-variant: the "Search" and "Search results" pages feature a destination filter ("Bestemming" on the BL/NL version). There are three fields with complex interaction. Both when using navigation with the keyboard or when using reading software unexpected behaviour occurs. It is not possible to mention all issues but this functionality fails 1.3.1, 2.4.3, 2.4.7 and 4.1.2. The best way to make this function accessible is a coordinated effort between a frontend programmer and the UX design/accessibility side of things.

4.1.3 Status Messages (Level AA)

Information about success criterion 4.1.3 Status Messages

Finding 41: React / B-variant: each page features a search option under the header. Upon input search results automatically appear, although this is not announced. Integrate the role="status" attribute so users of accessibility aids are notified of the new content.
Non-react: identical issue.

Basis for this evaluation

The audit was conducted based on the evaluation method of the W3C, WCAG-EM. This is largely done manually by taking a sample. For a quickscan we use parts of this methodology. Despite all the researcher's care and experience, it is possible that a problem has not been identified. Keep in mind that in a next audit certain parts could be assessed differently because of further development of techniques and assistive software. Tools are used in the manual audit.

Sample of audited web pages

• Search NL React:
  https://www.sunweb.be/nl/vakantie/zoeken-b-variant
• Search NL No React:
  https://www.sunweb.be/nl/vakantie/zoeken
• Search results DK React:
  https://www.sunweb.dk/rejser/sog-b-variant
• Search results DK No React:
  https://www.sunweb.dk/rejser/sog
• Search results FR React:
  https://www.sunweb.fr/vacances/recherche-b-variant
• Search results FR No React:
  https://www.sunweb.fr/vacances/recherche
• Search result NL React:
  https://www.sunweb.nl/vakantie/egypte/rode-zee/el-gouna/hotel-three-corners-rihana-resort-rihana-inn
• Search result NL No React:
  https://www.sunweb.be/nl/vakantie/egypte/rode-zee/el-gouna/hotel-the-three-corners-rihana-resort-rihana-inn

Relied upon techniques

• HTML5
• CSS
• WAI-ARIA
• DOM
• ECMAScript 5
• SVG

Resources:

• Website Accessibility Conformance Evaluation Methodology (WCAG-EM)
  www.w3.org/WAI/eval/conformance
• Web Content Accessibility Guidelines (WCAG)
  www.w3.org/WAI/intro/wcag
• How to Meet WCAG 2.1 Quick Reference
  www.w3.org/WAI/WCAG21/quickref/

This report is mainly created with the online W3C report tool.