OKCupid Accessibility Testing

okcupid[1].png
 

A standard error message given on WebAIM which allows developers to assess problems on their webpages.

 

Challenge and Goals

This report was generated as an assignment for a Disability & Assistive Technology class, part of the certificate program in Information Accessibility, Design, and Policy. The goal of the assignment was to assess the accessibility of a website (of our choice), rank its flaws and suggest possible fixes.

Process

The process of generating this report is fairly straightforward but followed many steps. The biggest of these is testing with various forms of assistive technology (AT). Using a wide variety of AT, I was able to conduct several tests, ranging from assessment of images and links to semantic errors in heading levels, labels, and more.

I first visually inspected the website code and ran it through a couple automated tools to catch most violations. These are often easy to spot and equally easy to fix, but often get overlooked in the development process. Then I utilized Windows Narrator to test the screen-readability of the site, followed by keyboard navigation tests. These sorts of tests are better handled with JAWS or VoiceOver, but I was limited by my own hardware. 

Having finished the evaluations, I then generated a report of recommendations for developers, an excerpt of which is below.


Report Excerpt

Automated Tool Evaluation

I conducted my evaluation using the WebAimWAVE tool. The tool discovered 20 errors, generated 7 alerts, and a whopping 92 contrast errors. This reviewer’s official recommendation is that the website is wholly inaccessible, as there are 3 or more S-level errors present. It is recommended that these errors are immediately corrected before reading any more of the following report.

  1. S-Level errors
    1. There is one instance of no alt text being present for a button. The button in question is the “Continue” button that is offered to agree to the terms and conditions. While this would not strictly impede the user, it is the opinion of this reviewer that not having context to what the button is referring to (agreeing to ToS) would not adequately inform individuals to the legal aspects of the service.
      1. This would fall under WCAG Guidelines of operability and perceivability. Specifically text alternatives (1.1) and link purposes (2.4.4).
    2. There are 11 instances of missing form labels. 5 of these missing labels affect the gender and sexuality drop-down menus, personal information (birthdate, email confirmation) forms and sign-in forms (whether connecting with Facebook or not). Being that this is an online dating service, not having tags to label or announce which menus allow one to select gender or sexuality, as well as inputting personal information to sign up for the site, would bar users from using the site as its intended to be. Even if a user were able to muddle through it, they may end up selecting the completely wrong options, leading to problems.
      1. These labels would improve WCAG Guidelines on navigability, link purposes, and consistent identification (2.4, 2.4.4, 3.2.3, 3.2.4 respectively).
    3. Several buttons are ‘empty buttons’, meaning there’s no text to convey what these buttons do. These are largely located in the gender and sexuality selection areas. One is also located in the “interested in” section, where the user indicates who they are seeking – men, women, or everyone. Again, as this is an online dating service, these aspects are crucial to the website functioning as intended, and having these errors renders the site inaccessible.
      1. Again, this is related to navigability and link purposes.

End Excerpt

Follow this link to read the whole report in a new window.


These reports are crucial for developers to use during a remediation process, if needed. They also often include screenshots such as the one here, which better allows one to see precisely where a problem area exists. In this example, the three red errors on the social media links indicate the link text is empty. In this case, a blind or LV user would have no idea a) that these are social links and b) where they might be directed if they click on them.

Take Aways and Impacts

This was my first foray into the world of accessibility testing and I learned a lot. I was able to successfully utilize a combination of automated tools, visual/manual inspection, and technology in hand to conduct a complete accessibility report. I utilize this skill in all aspects of UX work now to ensure the best possible experience for all users.

This was also my first major exposure to forms of AT other than voice dictation software, and I accordingly gained experience in the usage of those software and other kinds of tweaks - like Google accessibility settings on Chrome - to obtain a holistic view of a website. I now regularly utilize these settings and the developer's console to see how many websites (especially those offering a service) comply with accessibility standards.

Perhaps most notably, I internalized that visually pleasing design ≠ accessible design. Moving forward from that class, I have learned how to combine the two to create visually pleasing accessible designs utilizing ARIA and CSS. 

Reports and assessments like the above can have far reaching implications, offering a completely redesigned experience for ALL users, regardless of their ability or AT they use. In the case of OKCupid, a website that makes dating free and open for everyone, I was shocked to learn through this report that it really wasn't for everyone. By utilizing better drop-down menus and labels, that could've been avoided.