Do New York City mayoral candidates have accessible campaign sites?

A few weeks ago I was watching the first Democratic primary debate for New York City mayor. There are nine candidates! I only knew of a few of them so I started visiting their sites to learn more.

Rather than learning more about their platforms, I was struck by the amount of notable accessibility issues. Suddenly I was opening DevTools to check color contrast ratios and tabbing around looking for focus indication. Before too long I created a spreadsheet to track what I was finding, and the findings were not good.

According to the Web Accessibility Initiative (WAI) web accessibility is defined as “websites, tools, and technologies that are designed and developed so that people with disabilities can use them”. The Web Content Accessibility Guidelines (WCAG) provide detailed information to help ensure that what we build on the web can be used by everyone.

Since it’s unlikely that either of the Republican candidates will win, one of these nine will become the next Mayor of New York City. What does the lack of accessibility in their campaign sites say about their commitment to accessibility for the citizens of New York City? Or their commitment to an equitable and inclusive New York City?

Also of note, nine candidates hired nine teams to create their sites and not one of them created a fully accessible site. As much as this an unfortunate statement about the candidates, it also highlights that creating digital experiences that work for everyone is not even close to being the norm.

First and foremost, I am not an accessibility expert and this is not a proper accessibility audit! I’m a designer, developer, accessibility advocate and a citizen of New York City.

• This is a high-level look at the basics only, For example I looked at heading levels but not the overall structure and semantics of the page.
• The candidates could address every issue I found and their site could still not be accessible! Although any fixes would improve accessibility, which is always a good thing.
• This is not a design review or critique.
• The What’s being reviewed section goes into detail about what is reviewed, but here’s what is not reviewed:
  • Aria usage.
  • Page structure and semantics beyond heading levels.
  • Contrast on hover states.
  • Text links visually indicated by something other than color (e.g., underline, with an icon).
  • Meaningful alt text, although it is mentioned in a few places.
  • Whether sites using motion respect user settings.
  • Whether a site had dark mode and respected user settings.

• I only reviewed the homepage of each site.
• I used a combination of manual checking, ARC Toolkit plugin, WAVE, W3C HTML Validator and Page Speed Insights.
• I only tested on desktop primarily using Chrome, Safari and Firefox (my browser of choice).
  • Did not review on mobile.
  • Did not review with a screen reader or any other assistive technology.

I chose 10 items to review for each of the candidate’s sites. In the course of writing this post a few of the sites have made updates and one site was completely redesigned. The last in-depth reviews were done over the last weekend in May with spot checks done in the days leading up to publishing this post.

I’ve included a candidate scorecard in each review section as well as a section for each candidate that includes their full results with more detail about each review.

Explanations in the review criteria are not inclusive of all the ways in which visitors may use the sites, and are meant to give some examples to illustrate the importance of the standards.

As a general rule, keep in mind that you can’t predict all the ways your visitors choose to browse the web. — Hidde DeVries

A “Skip Link” allows people using keyboards, screen readers or other assistive input devices a way to bypass a site’s navigation and skip to the main content. A sighted person using a mouse can easily scroll to a site’s main content, but keyboards, screen readers and other assistive devices traverse the page sequentially using focusable elements such as links, form fields and buttons. Providing a “Skip Link” ensures that everyone can easily navigate through your site.

To test for a “Skip Link” press the tab key after the page has loaded, if a “Skip Link” is present it will typically appear in the upper left corner or centered at the top of the screen.

Candidates passed: 4 out of 9

• WebAIM: Skip Navigation Links
• Digital A11y: Understanding SC 2.4.1 Bypass Blocks
• TetraLogical YouTube: Quick Accessibility Test - Skip Link
• CSS Tricks: How to Create a “Skip to Content” Link

Dexterity issues or motor impairment are a few of the reasons someone may use a keyboard, switch or other type of assistive input device to interact with your site.

Unlike using a mouse, a person using a keyboard or other device has to navigate sequentially through the site, tabbing through links and other focusable elements.

To test the candidate’s sites I used the tab key to see if I could make it all the way through their homepage in a logical order with the ability to interact with all of their content.

Candidates passed: 4 out of 9

• TetraLogical YouTube: Quick Accessibility Test - Keyboard Support
• Nielson Norman Group: Keyboard-only Navigation for Improved Accessibility
• WebAIM: Keyboard Accessibility
• W3C: Understanding Success Criterion 2.1.1: Keyboard

Visible focus indication goes hand in hand with keyboard and switch usage. Tabbing through a site with a keyboard navigates the page by sequentially moving through each element that can receive input. When the element is selected it is said to have “focus”.

Links, form fields and buttons are examples of elements that can receive input, also referred to as focusable elements. It’s crucial to visibly indicate that an element has focus to allow sighted visitors to quickly orient their location on the page.

Web Content Accessibility Guidelines (WCAG) AA standards requires focused elements to have a 3:1 color contrast ratio between the element and its background.

While tabbing through the candidate’s sites to check keyboard navigation I also checked for visible focus indication. If there was visible focus on some, but not all focusable elements it was counted as a fail. It was also counted as a fail if the visible focus did not meet the 3:1 color contrast ratio.

Candidates passed: 0 out of 9

• Google Accessibility Guide: What is Focus?
• W3C: Understanding Success Criteria 2.4.11: Focus Appearance
• Deque: How to Design Useful and Usable Focus Indicators
• Hidde Devries: Indicating Focus to Improve Accessibility

Sufficient color contrast between content and the background ensures that low vision and colorblind visitors are able read and interact with your content. It’s also helpful for all sighted visitors in conditions with low light or screen glare.

The Web Content Accessibility Guidelines (WCAG) has set minimum contrast ratios for text and non-text elements such as buttons, form fields and icons.

Text on background images can make meeting and testing color contrast tricky, and many of the candidates have text over background images. I used a mix of tools and manual spot testing when reviewing the candidates sites.

Candidates passed: 0 out of 9

• WebAIM: Contrast and Color Accessibility
• W3C: Understanding Success Criterion 1.4.3: Contrast
• Digital A11y: # Understanding SC 1.4.11 Non-text Contrast
• Who Can Use: Color Contrast Checker
• The A11y Project: Fixing contrast issues, on your own site and elsewhere

Heading levels refer to the HTML heading elements of h1 - h6. Correctly ordered heading levels have a number of benefits, including allowing screen reader users to listen to a list of all headings and skip to any one of them to begin reading.

A common mistake with headings is using them to apply font size. This approach typically results in non-sequential or missing headings. Several of the candidate’s sites did not have a h1 or skipped levels.

I included heading level outline in each candidate’s W3C HTML Validator test, it’s also included in their WAVE test. I’ve linked to the results of each in the candidate’s individual results.

Candidates passed: 2 out of 9

• W3C: Web Accessibility Tutorial - Headings
• WebAim: Headings

Alternative text, or alt text, is used to provide context about images. Alt text should be provided for images that convey information, but the alt tag can be left blank for purely decorative images (e.g., alt=""). If you’re not sure if an image is purely decorative or not, Caitlin Geier at the Deque blog suggests removing it from the design to see if any meaning or information is lost. If so, add alt text to ensure that screen reader users also get that information.

Another important use for alt text is that it renders the text on the screen if the image doesn’t load. This is helpful for people on slower connections and where visitors have turned off images to cut down on cognitive load or page load time.

Alt text testing is included in WAVE and I included it in the W3C HTML Validator test. Automated tests only pick up whether or not the alt tag is present and whether it has text or is left blank. It can’t tell if an image is decorative but in some cases can flag that text might not be meaningful. In addition to WAVE and the HTML validator I also did manual spot checks.

Candidates passed: 4 out of 9

• W3C: An ‘alt’ Decision Tree
• WebAIM: Alternative Text
• Deque: # How to Design Great Alt Text: An Introduction

Form inputs need a properly associated label in order to be accessible to assistive technologies. Another benefit is that clicking or tapping on the label puts the input in focus, which makes it easier for people with motor disabilities to select and enter information in a form.

It’s not uncommon to see placeholder text used in place of labels, or labels that are not properly associated to their inputs. I tested this using WAVE, the ARC Toolkit plugin and manually. I only tested to see if inputs had proper labels, not if the labels were meaningful.

Candidates passed: 2 out of 9

• Deque University: Form Input, Labels, and Instructions
• WebAIM: Creating accessible forms
• W3C: Web Accessibility Tutorials: Labeling Controls

People with low vision view content on their computers and phones by magnifying or zooming the screen. When the screen is magnified or zoomed the content reflows. The success criteria for content reflow is for content to be “presented without loss of information or functionality, and without requiring scrolling in two dimensions”.

This is important to ensure that visitors to your site don’t have to scroll horizontally when viewing magnified content. I zoomed each of the candidate’s sites to 400% to see if they were still usable.

Candidates passed: 1 out of 9

• TetraLogical YouTube: Quick accessibility test: Content resizing
• YouTube: Two ways blind/low vision people use smart phones
• YouTube: How a blind/visually impaired person uses a phone
• CSS Tricks: Accessible Font Sizing, Explained

An Accessibility Statement is a dedicated, clearly labeled page of a website that spells out the site owner’s commitment to the site’s accessibility. The intended audience should be all visitors to the site.

While there are no hard and fast rules about what’s included, the site’s current level of conformance and a way to provide feedback are considered the essentials as demonstrated by the Minimal Example at the W3C site.

Investis Digital points out an important consideration when writing an Accessibility Statement…

Remember that although having an accessibility statement is, in some cases, a legal requirement, it shouldn’t read like a legal document. Its target audience is your users. Avoid using technical or legal jargon, and make sure the content is written in a simple and easy to understand language. — Investis Digigal

Candidates passed: 1 out of 9

• Nomensa: How to write an Accessibility Statement
• Investis Digital: Writing an Accessibility Statement
• W3C: Developing an Accessibility Statement

There is no direct accessibility standard for the availability of JavaScript, but if all or some of your site depends on JavaScript to function it could cause issues if JavaScript doesn’t load. And if you consider the goal of accessibility to ensure that everyone can use your site, then this is an accessibility issue.

All your users are non-JS while they’re downloading your JS. — Jake Archibald

There are a number of reasons why JavaScript might not load. Some browsers turn off JavaScript on slow connections, or an extension can break JavaScript. And of course a visitor to your site may have it turned off by choice.

Considering these are content sites rather than transactional, it’s reasonable to assume they should be fully usable without JavaScript. While looking at candidate’s sites I found examples of backgrounds not loading, which led to contrast issues, and instances where the navigation was no longer accessible via keyboard. In most of the “fails” the forms didn’t load.

I disabled JavaScript and tried to view the candidate’s sites, if any element of the page didn’t load I counted it as a fail. In some case much of the site didn’t load and in others it was forms and/or images.

Candidates passed: 0 out of 9

• Adam Silver: JavaScript isn’t always available and it’s not the user’s fault
• Dev: Why your website should work without JavaScript

I used a few tools to help test the candidate’s sites. The following allow for direct links to test results and have been included in the candidate’s individual section.

WAVE is a free web accessibility evaluation tool created by WebAim. When testing via the WAVE site the results are available by copying the URL of the results report. It’s also available as a Chrome or Firefox extension.

The W3C HTML Validator is a free markup validation service. All the candidates site’s had an eye-opening amount of errors. I’ve included the document outline, which shows the heading levels and a report on images, which is relevant to alternative text.

Page Speed Insights is a free performance evaluation tool from Google that includes results for Core Web Vitals. Like JavaScript availability there is no direct accessibility standard around performance, but visitors on slow connections with lower end devices may have a harder time using your site if the performance is poor. While I didn’t use it in these evaluations, WebPageTest is another useful performance evaluation tool.

The full results for each candidate includes a link to their site, what platform they’re using, their overall score, a summary, a few example images, details for each review and links to their automated test results. The candidates are ordered alphabetically by first name.

Yang for New York
Platform: Gatsby
Reviews passed: 1 out of 10

While Yang’s site is navigable by keyboard, the carousel behavior is not consistent, which could lead to confusion. Overall the had a wide variety of issues including no “Skip Link” many color contrast issues and inconsistent use of focus indication.

• Page Speed Insights
• WAVE - Ran locally due to scripting error using web based service
• W3C HTML Validator

Dianne Morales for NYC Mayor
Platform: Squarespace
Reviews passed: 3 out of 10

Overall the site has good contrast and focus indication but a few frustratingly close contrast ratios kept those areas from passing. The site has a Skip Link and most of the site was navigable by keyboard with the exception of the fixed “Language” widget.

• Page Speed Insights
• WAVE
• W3C HTML Validator

New York City’s Next Mayor
Platform: WordPress
Reviews Passed: 1 of 10

Several of the review criteria was a mix of pass and fails, such as a single missing alt tag and one form with correct label usage and one without. The other candidates sites were mostly usable with JavaScript, only missing a few elements, but Adams’ site barely loaded and had layout issues. One positive example was the “Candidate fully invested” section had good color contrast against an image background.

• Page Speed Insights
• WAVE
• W3C HTML Validator

Garcia for NYC Mayor
Platform: WordPress
Reviews passed: 2 out of 10

Garcia’s site has a Skip Link and several areas with with good contrast. One easy to fix failure is the form labels, they are implemented correctly to use an id to associate them to their inputs, but the id on each input is duplicated in both forms (e.g., both email inputs use id="form-email"). Another issue with the forms are that the floating labels are illegible when typing in the inputs.

• Page Speed Insights
• WAVE
• W3C HTML Validator - There was a fatal error at the 12th error and it could not complete.

Maya for Mayor
Platform: Next.js
Reviews passed: 3 out of 10

Wiley’s site overall has very good contrast with some relatively easy to fix exceptions. She is also the only candidate with an Accessibility Statement, I’ve sent an email with my findings and will update this post (or write another one!) if hear back. The biggest fails were lack of a Skip Link, no focus indication and almost no alt tags. There were also issues with forms.

• Page Speed Insights
• WAVE
• W3C HTML Validator

Ray for Mayor
Platform: Squarespace
Reviews passed: 5 out of 10

McGuire’s site had the best showing of the group overall and could be easily improved with a few fixes. Another notable aspect of the site is the simplicity of the homepage. While most of the candidates loaded their homepages with carousels, images and multiple sections, McGuire’s homepage is straight forward and easy to navigate regardless of the method.

• Page Speed Insights
• WAVE
• W3 HTML Validator

Stringer for Mayor
Platform: WordPress
Reviews passed: 2 out of 10

Stringer’s site was one of only two that had proper form labels. The site also did well with alt text, but there were several contrast and focus indication issues. One notable was issue is a fixed “Join Team Stringer” banner at the bottom the screen. It was not in the proper order for keyboard navigation, and it remained in the tab order if the banner had been dismissed and was no longer visible.

• Page Speed Insights
• WAVE
• W3 HTML Validator

Shaun Works for NYC
Platform: WordPress
Reviews passed: 2 out of 10

Donovan’s site has a Skip Link and proper alt tags, but there were plenty of contrast and focus indication issues and the carousel of Tweets caused problems keyboard navigation issues.

• Page Speed Insights
• WAVE
• W3 HTML Validator

Does a candidate’s lack of an accessible campaign site mean they won’t be a good Mayor for disabled New Yorkers? Of course not, but it also doesn’t inspire confidence. Alternatively, the candidate whose campaign site was the most accessible (by this high-level overview at any rate) isn’t guaranteed to be the best candidate for an accessible, equitable and inclusive New York City.

I hope that by highlighting the relative inaccessibility of these sites that it brings more awareness to the importance of ensuring that all experiences work for everyone. Please contact me via email or on Twitter if you have any feedback or suggestions regarding this post.