The ACM CHI Conference on Human Factors in Computing Systems is the premier international conference of Human-Computer Interaction (HCI). CHI – pronounced 'kai' – annually brings together researchers and practitioners from all over the world and from diverse cultures, backgrounds, and positionalities, who have as an overarching goal to make the world a better place with interactive digital technologies.

Our assumption at the moment is that CHI 2022 will be structured in two phases: (1) a 2-day Web-Exclusive phase occurring on April 13–14, followed by (2) a Hybrid-Onsite phase from April 30–May 6 in New Orleans, LA.


CHI 2022 Website Accessibility

CHI 2022 Website Accessibility

We are trying to make all the aspects of CHI 2022 as accessible as possible to everyone. Making the CHI 2022 conference website accessible is part of that effort. In this blog post, we share what members of the organizing committee have been doing to make the website accessible.

An accessible web site is one that can be used efficiently by people in a variety of ways. Some of our community members use large fonts, high contrast color settings, or screen magnification. Others listen to web pages and navigate them using a screen reader. Some people use only a keyboard, or a braille display. Some of us have color vision differences, or are sensitive to animation or clutter. Some rely on captions or transcripts to receive audio information. Our goal is to make information about CHI easily accessible and easy to navigate, no matter how each user approaches it.

In the process of making and deploying the CHI 2022 website, the Web Chairs designed the site with accessibility in mind, and the Accessibility Chairs evaluated the site’s accessibility. All pages on the website were designed and generated using WordPress; the Web chairs edited the WordPress’s HTML templates to adhere to W3C Web Content Accessibility Guidelines (WCAG 2.1), more specifically WCAG 2.1 AA standards. Accessibility Chairs then assessed the accessibility of the landing page and subpage that were generated from those templates. Following the SIGACCESS Accessible Conference Guide and IBM’s Accessibility Checklist, Accessibility Chairs evaluated the website with the four-step process, which involved:

  • Automatic test of whether the pages met basic accessibility requirements (e.g., presence of alt text for figures) using Equal Access Accessibility Checker, Lighthouse, and Wave tools.
  • Manual test of whether the controls (e.g., links) can be reached and operated just with a keyboard.
  • Manual check to see if magnifying the content and changing the contrast break the design of the web pages.
  • Manual test of the navigability of the web pages with screen readers using NVDA on a Windows desktop computer and VoiceOver on a MacBook Pro.

We identified a few minor accessibility issues that would not prevent people from using the web site. We reported those minor issues to the Web Chairs.

Automated Accessibility Check

Lighthouse and Wave allowed us to identify accessibility problems in the early version of the WordPress templates. Lighthouse, a tool that can be used through Google Chrome’s DevTools, provides a score of how accessible the page is and reveals accessibility problems if any can be automatically detected. Wave is another tool that allows us to inspect the accessibility of a web page. We used the two tools to uncover as many accessibility problems as possible. Although automated tools cannot find all accessibility problems, they are an important first step.

Keyboard Accessibility

Some of our community members use a keyboard and no mouse, so we manually tested whether we can navigate the web page with only a keyboard to assess keyboard accessibility. We:

  • Checked to see if a user can use a Tab key to navigate through interactive elements (e.g., links).
  • Assessed intuitiveness of keyboard-based navigation order and comprehensibility of website sections.

All the links on the page could be reached using a Tab key (and Shift+Tab) alone, and we could jump to the target web page by hitting Enter key. The structure of the web page was simple and intuitive to navigate. Because there were no custom widgets like dialog boxes and form elements, we did not test their accessibility.

Magnification and Contrast Cadjustment

We manually tested if controlling the font size and contrast would affect the accessibility of the web site. We used the operating system’s built-in zooming features (e.g., magnifier in Windows, macOS’s zooming feature) and the browsers’ zooming features (e.g., Google Chrome’s zooming feature). We visually inspected the DOM reflow at 200% zoom level on Google Chrome; WCAG standards require that readers should be able to increase the font size up to 200% without breaking the page layout. We did not identify any breaking issues with the page layout.

We also used Google Chrome’s “High Contrast” feature to invert screen color, greyscale and adjust contrast to see the visibility of the web contents. Manual inspection of the color inverted and contrast adjusted content showed that the web page contents are legible even after the adjustment.

Screen Readers

To assess the accessibility of the website with a screen reader, we manually inspected with VoiceOver and read out the web page content on macOS and iPhone. We used NVDA to assess the screen readability on Windows. We found that the reading experience was good and did not identify any noticeable accessibility problems. The Assistant to the Accessibility co-chairs, who is blind, evaluated the site with a screen reader.

Questions or Concerns

If you have any concerns or identify accessibility issues, please contact our Accessibility Chairs, Dhruv Jain, Garreth Tigwell, Zainab AlMeraj, and Kotaro Hara by email:, and someone will respond to you shortly.