// Case Study
Theatre Development Fund
Search & Filter
The Theater Development Fund (TDF) has been working since 1968 as a not-for-profit service organization providing support to theatrical works of artistic merit. For decades, they have worked to encourage and enable diverse audiences to attend live theater and dance productions.
Art+Logic began working with TDF in 2010 developing a series of native mobile applications — first for the iOS platform and then Android — that would allow users to search for discounted tickets for shows available at TDF’s TKTS booths. In 2015, we were asked to prepare a proposal to redesign the current TDF site to be ADA compliant. Based upon our recent work redesigning another company’s website for ADA compliance, we developed a detailed plan of implementation for TDF. We lost the bid due to the projected cost of the effort, however, we continued to keep in touch with our primary client contacts at TDF.
In early 2017, TDF reached out to us again. The new ADA site had launched but it wasn’t meeting ADA standards and the design was clunky. In reviewing our earlier proposal, TDF realized that we had identified areas of focus, best-practices, and standards that were sorely lacking in their current site.
Art+Logic began a collaborative effort with TDF to bring the current website up to ADA compliance, streamline navigation, and improve overall look & feel.
Ada Lawsuits and Accessibility
// Goals + Objectives
The previous development team had taken a first pass at creating an accessible UI/UX design, but fell short. Upon our review, we also discovered that much of the search logic was hardcoded in the application. This hardcoding would prohibit scaling in the next phase of the project, which involved more filtering options on more accessibility needs in more combinations.
So, the goals of the project became:
- As quickly as possible, redesign the current site using proper page structure and applying ARIA tags, ensuring users could navigate the site via screenreader.
- Make the site look cleaner and tighter.
While doing this…
- Scrub out the hardcoded logic in the current application to align with the necessary data-driven application model.
- Investigate API integration with the ticket vendors — Telecharge and Ticketmaster.
After releasing the updated website…
- Extend the search and filtering functionality.
- Update the Admin CMS to reflect the new database supporting the data-driven application.
- Integrate ticket vendor APIs, mapping the various naming conventions and ADA offerings for each venue to our database.
In January of 2017 the producers of “Hamilton” and the theatre it plays in were sued for violations of ADA compliance. The lawsuit was designed to spotlight accessibility issues for disabled theatre-goers. It is important to note that the theatre community is progressive in its efforts to ensure that performances are accessible to all theatre attendees, however, as noted in the lawsuit, more can be, and should, be done, to create parity in experiences: both in the ability to enjoy a performance and in the ability to access information about a performance.
The objective was to create an end-to-end ticketing search and purchasing experience for the user seeking to find and buy ADA accessible tickets to their favorite Broadway show. Across a broad range of needs — Autism-friendly, sign-language interpreted, closed-captioned, and more — we wanted to provide an intuitive, empowering, and clean solution for users rather than dumping them to a general box office phone number or TTY service, as was the norm for many theaters.
// UI Design
Design for a diverse set of users who will interact with the site using various assistive technologies, i.e.: VoiceOver, TalkBack, JAWS, etc.
We designed and developed the site with keyboard access and screen readers as the driving force for the user experience. Rather than our normal “visual” approach to UI design, we re-imagined the site by “listening” and navigating the site using only keyboard controls. We crafted a solid HTML5 framework following WCAG and WAI-ARIA guidelines. We setup properly organized headings and verbose labels and descriptions to ensure that navigation and instructions were always clear. The end result is a fully accessible, keyboard friendly, ADA-compliant site that theatre goers can use to find accommodation-specific shows on Broadway.
There are a couple free tools available for checking a website for ADA compliance. The one that we found most valuable was the WAVE tool provided by WebAIM, whose mission is to “empower organizations to make their web content accessible to people with disabilities.” For each URL entered, it finds and reports on issues specifically related to Section 508 of the Rehabilitation Act of 1973 as amended in 1998.
// Quality Assurance
Testing any website is a challenge. A list of browsers, possibly including different versions for each browser, needs to be identified upfront. Then, there are the various platforms and devices on which each browser needs to be tested. Windows. Mac O/S. iOS. Android. The list goes on. In addition to testing each browser on each platform/device, there are a number of principles for good website design that testers need to think about while they are exploring the site. Is the site intuitive? Is navigation easy to use and working as expected? Is the information easy to find and understand? And so on. Making sure that a website is also accessible to users with disabilities takes testing to a whole new level.
The 1st testing challenge
To understand what makes a website accessible to people with disabilities. In order to test for accessibility, a tester needs to understand what makes a site accessible. Fortunately, there are many excellent resources that can help guide this process.
Based upon the Web Content Accessibility guidelines, there were new questions that needed to be asked during each phase of testing.
- Are there text alternatives for any non-text content?
- Can users see and hear content? Is content accessible via the keyboard as well as mouse?
- Do users have enough time to read and use the content?
- Are users able to avoid and correct mistakes?
- Is the site compatible with assistive technologies? And many others.
The 2nd testing challenge
Learning how to use assistive technologies such as VoiceOver on Mac and Talkback on Android. To be honest, this wasn’t easy at first. Stressful even. It took a week or two of regular use to master the commands and remember how to interact with the site. At that point, it was time to start looking at whether all elements were accessible in these tools.
- Were they in the right order?
- Were they named properly?
- Was the content organized?
- Did the web page flow?
- Was anything confusing?
“Web Content Accessibility Guidelines (WCAG) 2.0 defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability. These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general.”
Technology did not always appear to operate consistently for different users on our team or even on the same device.
The third testing challenge was trying to think like a user. That is always part of the testing process. If I were a user, what would I do? How would I use this feature? In the case of accessibility testing, this process was even harder. It required more than just testing to see if a feature was accessible using VoiceOver, for example, when the tester can see! This created a new set of questions. If I could NOT see, would I not only able to use this feature but would I be able to find this feature? Would I know how to use this feature? Are their clear instructions? Do I know how this feature fits within all of the other content? If I use the feature, do I know whether it was successful or not? What were the results? With each feature that was developed, there were more questions to be asked and answered.
Thinking like a user was a learning process in itself.
Finally, each assistive technology needed to be tested with various browsers as well as on different devices and platforms –- and within the usual constraints of a budget and a schedule.
// Business Logic
Provide complex search capabilities while minimizing user effort. More specifically, filter by combinations of accommodations, dates, and, optionally, a partial name of a show or theatre.
As with many data-heavy systems, we chose to address this challenge bottom-up. We increased the normalization of the database to improve the clarity and efficiency of the mapping between shows and their accommodations. Within the application logic, we ensured that the filters were applied in an effective order. Moreover, to save user effort, we persisted most of the filters in a long-term cookie so that they would not need to be re-entered repeatedly; however, we stored the optional search string in a short-term cookie so that the user would not have to go through the trouble of resetting it after a search. In the browser, we relied on HTML attributes to support the CSS styles and ARIA capabilities to help users select the filters and get the results.
TDF supplied a number of real-world users of the site and solicited their feedback on iterations of the site, ensuring we were meeting user needs. In some cases, we mocked up variants of the UI and associated behavior to allow for A/B-testing of user flows. We also worked with TDF to solicit and secure API access to several of the ticketing companies like TicketMaster and Telecharge in an effort to provide a seamless purchasing experience to users; this hasn’t always been easy though, as these ticketing agencies are lagging behind in the granularity of information they can provide with respect to Accessible services.
// The Team
Technical Lead, Developer
people worldwide who, due to some disability (i.e. they are suffering with low vision), cannot read all content on a website.
39 million of those people are blind and cannot access any of the content without using assistive listening technology.
of web accessibility-related litigation and settlements since 2000 happened in the past three years
Mobile screen reader usage has increased by 70% from 2009 to 2014