Oct 08 2019
Oct 08

This week, the U.S. Supreme Court declined to review California’s Ninth Circuit Court’s decision in Robles v. Domino’s Pizza, LLC,* signaling a long-anticipated answer to an essential question: Does the Title III of the Americans with Disabilities Act, which was written in 1990 before the current digital landscape was ever envisioned, apply to websites and apps?
The answer: Yes.
 
Until now, the legal mandate surrounding the accessibility of websites and apps has been shrouded in ambiguity. This decision needs to be viewed as a loud wake-up call for businesses who want to avoid legal action and unwanted attention to what their websites might be lacking.
More so than ever before, businesses that delay in having their sites thoroughly evaluated for accessibility and remediated as necessary are at risk. This ruling also opens up the flood gates for accessibility lawsuits

The US Courts Have Spoken on Web Accessibility  

In deciding not to hear Robles v. Domino’s Pizza, LLC, the Supreme Court has upheld that:
    •    Title III of the ADA covers websites and apps that have a connection to a physical place of public accommodation, and 

    •    Holding businesses that do not have an accessible website liable, does not violate their 14th Amendment right to due process.

In rejecting the appeal from Domino’s Pizza, the Supreme Court cleared the way for Guillermo  Robles, a blind man, to proceed with his lawsuit against the chain. His lawsuit alleges that Domino’s website and mobile app were not accessible to him, and that under Title III of the Americans with Disabilities Act, he had a right to require that the site be outfitted with accessibility aids. 

The issue that brought Dominos to the Supreme court was a missing Alt Text!

Robles v. Domino’s was filed in the Central District of California in September 2016, and centered on the inability of Robles to order a pizza on his iPhone: The app didn't accommodate his screen-reader software, which works only when a website's graphics have an "alt-text," feature that gives a description of the image when a cursor floats over it.

The Ninth Circuit held that websites and mobile apps should be considered among the “places of public accommodation” covered by Title III of the Americans with Disabilities Act. While Domino’s argued that Title III of the ADA was intended to apply to accommodations in its physical restaurants the Ninth Circuit held that websites and apps now constitute places of public accommodation.

What does this mean for private website owners?

Let there be no doubt, the floodgates have now been opened for disabled plaintiffs to take legal action against companies whose websites and mobile apps are not accessible. 
While some claim that there is still a lack of clarity concerning web accessibility requirements, WCAG 2.1 currently stands as the definitive guidelines for remediating existing sites or building new ones.
The impact of the Supreme Court’s decision to not hear is decision cannot be underestimated. The disabled rights community has been closely watching this case and this week’s development needs to be viewed as a loud call to action for all businesses that have a website or app that’s designed to serve as a point of public accommodation.

At Promet Source, walking clients through the process of evaluating their websites and mobile apps for accessibility and moving forward with the confidence that compliance has been achieved, is what we do. And time and time again, clients discover that remediating their site for accessibility is a value-added process that results in a wide range of benefits.

Never has it been more critical to partner with an expert and get it right. We’re here to help. Contact us today.

*Supreme Court Declines to Review Ninth Circuit Decision in Robles v. Domino’s, Exposing Businesses to More Website Accessibility Lawsuits, by Seyforth Shaw, LLP, Oct. 7, 2019
 

Feb 23 2017
Feb 23

Why should I load test my site before launch?

Website load testing is used to simulate user interaction with a website, increase the frequency or the number of interactions, collect the results of system usage, and then analyze them to aid in system improvement towards desired results.

There are three key phases of performing load testing.

- Analysis & Acceptance: Obtain a prediction of potential load and agree on Acceptance Criteria

- Behaviour: Plan and design the test cases and test steps that represent typical usage and prepare the target environment

- Execute, Modify & Repeat: Execute the test and measure the results. If necessary, implement improvements and repeat.

Website Load Testing Phase 1: Analysis and Acceptance


Typically during site migrations we analyze previous site’s traffic by looking at google analytics. We look for traffic patterns and interaction patterns. Looking for highest pageview days over a period of a year or more gives us an idea of typical peak load. Sometimes the trends are seasonal, as in eCommerce sites, so it’s important to look at a longer period of time. User interaction patterns give us an idea on how the end user interacts with the site: how they are logging in, which pages are most popular, how many pageviews are typically generated by the user, what actions they perform. From this data we will create target load numbers and use cases. Then, we can agree on the acceptance criteria of site performance. Those criteria may include total number of error free requests per minute, Apex scores or average response times.

load testing site traffic overviewload testing site traffic overview image 2

Website Load Testing Phase 2: Behaviour

Build test cases and test steps that will be run by the load test. Sites that provide information typically have scripts that simulate several users consuming information on some of its popular pages. Applications will have scripts which run the user through achieving a goal, such as signing up for an email, creating an account, searching for specific content, etc.

Website Load Testing Phase 3: Execute, Modify & Repeat  


At Promet Source, we prefer to use Load Storm for test execution along with New Relic on the server. Load Storm spins up cloud servers which simulate user behaviour through browser requests. It collects the data on each request and provides a graphical representation of the results. By using New Relic, we are able to see performance patterns. We look for average response times, peak response times, slow responding requests, and error rates in order to find a point of failure. New Relic gives us the ability to fine tune the site by providing insights into database performance, which modules or transactions take the most time to complete and shows us which parts of the application have the heaviest usage. This data gives our development team visibility into where the site limitations are and where to focus our efforts.

Load Storm User Testing Graph image

At the conclusion of load testing the application performs better and everyone (most importantly, the client) has peace of mind that once the site goes live it will be a pleasant user experience for both the end user and the technical staff or internal development team supporting the site.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web