top of page

Chandigarh Tourism Website  

Web Accessibility Evaluation • WCAG 2.1 • Manual & Automated Accessibility Evaluation

Project Overview

I evaluated the Chandigarh Tourism website, which serves as the primary information platform for visitors to Chandigarh, a city renowned for its architecture designed by Le Corbusier. As a major tourist hub, especially during the winter season, the website plays a crucial role in providing accessible, user-friendly information to a diverse audience. My evaluation focused on the site's usability, accessibility, and ability to cater to a wide range of users, given its importance in supporting the city’s thriving tourism industry.

Fall 2022 • 12 weeks

Accessibility Tools Used

For the manual accessibility of the Chandigarh tourism website, I used the JAWS Version 2023.2210.29 ILM as a screen reader, and Google Chrome Version 107.0.5304.87

​

I used two tools for the automated accessibility evaluation. They were ‘WAVE’ and ‘Accessibility Insights for Web’. For both the tools, I used their web versions.

Untitle1d-1.jpg

Manual Accessibility Evaluation

Keyboard navigation

Focus management

Knowledge-Management-Process-and-Its-Implementation_middle-image-02 copy.jpg

Screen reader testing

Color contrast checks

Visual inspection

Untitled-1 copy.jpg

Manual Accessibility Inspection

I identified a total of 17 errors on the webpage, including missing alternative texts on images, invalid use of language, empty links, and color contrasting errors. Top 4 are highlighted below.

WCAG Guideline: 3.1.1 Language of Page (Level A)

 

The default human language of each Web page can be programmatically determined.

​

Screenshot 2024-10-07 at 3.46.18 PM.png

The language of the document is not identified in the code (marked in the image above). Identifying the language of the page or page elements allows screen readers to read the content in the appropriate language. It also facilitates automatic translation of content. The website failed the 3.1.1 criteria which states that the language of a web page can be programmatically determined. The easiest way to fix the violation is identifying the document language (in this case, English) using <html lang="en">.

WCAG Guideline: 2.4.4 Link Purpose (In Context) (Level A)

​

The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

​

Screenshot 2024-10-07 at 3.49.10 PM.png

The screen reader showed that images did not have alternate text. For example, the linked image (top left, marked in green) is missing an alternate text in the HTML code (marked in green). An image without alternative text results in an empty link. When an image does not provide alternative text, a screen reader has no content to present to the user regarding the function of the link. 10 different images on the website is missing alternate texts, this being one of the examples.

WCAG Guideline: 2.4.7 Focus Visible (Level AA)

​

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

​

Screenshot 2024-10-07 at 3.51.40 PM.png

The homepage has headings for information updates. Several headings like Places to Visit and Accommodation have information under them. When the screen reader was on, the keyboard operable user interface did not have a mode of operation where the keyboard focus was visible. This is important for deaf users, where they know where to find what on the website. This is present all throughout the website, and this is one of the many examples.

WCAG Guideline: 1.4.3 Contrast Minimum (Level AA)

​

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1.

​

Screenshot 2024-10-07 at 3.53.23 PM.png

There is a very low contrast between text and background colors. Adequate contrast of text is necessary for all users, especially users with low vision. An increase in the contrast between the foreground (text) color and the background color needs to be done. The colors used do not fall under the contrast ratio of 4.5:1. Currently, with the low contrast the website is violating WCAG 1.4.3.

Untitle1d-1.jpg

Automated Accessibility Evaluation

WCAG compliance

ARIA validation

Knowledge-Management-Process-and-Its-Implementation_middle-image-02 copy.jpg

Accessibility scanner

Code
validation

Automation scripts

Untitled-1 copy.jpg

Automated Accessibility Inspection

I used two tools for the automated accessibility evaluation: ‘WAVE’ and ‘Accessibility Insights for Web’. For both the tools, I used their web versions. Top 3 errors are highlighted below.

WCAG Guideline: Contrast Minimum [1.4.3 (Level AA)]

​

Error: Both, manual and automated accessibility testing methods, showed that the color contrast ratio did not meet WCAG guidelines for this website.

​

Screenshot 2024-10-07 at 4.25.05 PM.png

I first used the ‘Accessibility Insights for Web’ to check where all are the color contrast violations on the webpage. I then used ‘Wave’ and it showed me the same error. I also inspected the HTML code. The webpage has insufficient contrast color. This clearly violates the WCAG 1.4.3 guidelines. With a white background color of the website, the red shade should have been used in terms of the final ratio of 4.5:1. At present, the shade used matches the ratio of 4.1:1. The code is not helpful here, but the accessibility tools come in play.

WCAG Guideline: Language of Page [3.1.1 (Level A)]

​

Error: Language missing

Screenshot 2024-10-07 at 4.28.33 PM.png

When I checked the HTML code, the language of the document is not identified in the code (marked in the image above). Identifying the language of the page or page elements allows screen readers to read the content in the appropriate language. Both the accessibility tool checkers pointed this out. It also facilitates automatic translation of content. The website failed the 3.1.1 criteria which states that the language of a web page can be programmatically determined. The easiest way to fix the violation is identifying the document language (in this case, English) using <html lang="en">.

WCAG Guideline: Non text Content [1.1.1 (Level A)]

​

Error: : Linked images missing alternative texts.

Screenshot 2024-10-07 at 4.33.01 PM.png

The WAVE automated checker indicated that the images in the introductory section did not have alt-text. The HTML image element in the markup showed that all the images in the section were marked as alt=“”. The website does not provide screen reader users with an adequate alt text for their best user experiences as others. It violates WCAG 1.1.1 criteria.

Top Three Accessibility Improvements

The first (and main) accessibility improvement needed is adding alt text to all the images. WCAG 1.1.1 Non-text Content ensures that every image on the webpage has descriptive alt text. Currently, 14 images on the webpage are missing alt text, causing screen readers to have no content to present to users.

The second accessibility improvement needed is correcting the color contrast. WCAG 1.4.3 Contrast (Minimum) ensures that the visual presentation of text and images meets a minimum contrast ratio of 4.5:1.

The third important accessibility improvement is ensuring that the keyboard focus indicator is visible. WCAG 2.4.7 Focus Visible requires that any keyboard-operable user interface has a mode where the keyboard focus indicator remains visible.

Comparison: Manual &
Automated Accessibility Evaluations

During both manual and automated accessibility testing, the screen reader and tools identified that the text resizing links on the website were redundant, even though the option was available. The screen reader skipped this section while narrating the top links, and both WAVE and Accessibility Insights for Web flagged this issue. Additionally, both tests revealed that none of the images on the webpage had alt text. In the manual test, the screen reader did not narrate the images when they were highlighted, and the automated tools pointed out that 14 images on the webpage were missing alt text, with the HTML code displaying alt="" for each.

I realized that both testing methods highlighted similar issues, indicating that these are significant accessibility concerns for the website. When different testing methods point out the same flaws, it becomes clear that the website does not meet accessibility standards and requires corrections.

Contrast: Manual vs.
Automated Accessibility Evaluations

In the manual testing, I discovered that the screen reader occasionally missed highlighting some images where the alt text was missing. However, both WAVE and Accessibility Insights for Web identified all the missing alt text. For instance, on the top right corner of the website, there is an image of the Indian emblem (included because the website is government-operated). The screen reader completely ignored the image, while the automated tools flagged the issue.

From this exercise, I learned that manual testing is generally less reliable compared to automated tools. Human errors are inevitable, and manual testing is time-consuming. In contrast, automated tools, though more expensive, are quicker and provide consistent results. Manual tests may also produce different errors on different operating systems (e.g., Windows vs. macOS), whereas automated tools offer more consistency since they rely on software.

As an industry professional, I understand it can be challenging to choose between the two methods. While automation is not always possible for every software product, manual testing is still valuable in such cases.

Want to get in touch?
Drop me a line!

Thanks for your message! I will get back to you as quickly as possible :)

VERSION

​

2025 © by Utkarsh Chhadva

                      SOCIALS

​

GMAIL     |    TWITTER    |    LINKEDIN

bottom of page