Why US law effectively mandates all software design be responsive
Smashing Magazine defines “responsive design” as an approach where design responds to the user’s behavior and environment based on screen size, platform, and orientation. In responsive design, a breakpoint is the “point” at which a website’s content and design will adapt to provide the best possible user experience. Essentially, breakpoints are pixel values that a developer/designer can define in CSS. I can count on one hand the number of web pages I have bookmarked. Apple’s list of responsive breakpoints for iOS devices is one of them.
In a mobile-first world, you always do responsive breakpoints. Because, yeah, it’s mobile. But let’s say hypothetically your organization doesn’t live in a mobile-first world, and your officially supported environments are laptops and tower systems only. Your software is ridiculously complicated. Your organization is allergic to mobile; small form factors will never EVER work. “Why would you spend time designing and implementing responsive breakpoints for something that never will appear on a supported mobile device,” you may be asking yourself.
Simple. The Americans with Disabilities Act. If you are based in the US or selling something in the US, the ADA applies to you. Being headquartered outside the US does not exempt you from following the ADA.
Federal courts interpreting the ADA and local state versions like the California Unruh Act have been consistently holding that digital properties — software, websites, mobile apps, and electronic documentation — MUST be accessible to people with disabilities. A definition of accessibility standards for XR/VR is proposed to be added to WCAG 3.0 (aka Project Silver). Twenty-three hundred lawsuits were filed in each of the last two calendar years, with the plaintiffs winning the overwhelming majority of them.
The only slowdown seen in the first half of 2020 was due to COVID closing courthouses where only emergency cases were being accepted. American civil litigation returned to its “normal” pace of lawsuit filing in May. Seventy-five percent of the cases filed to date in 2020 have cited WCAG 2.1 Level AA in the plaintiffs’ complaints as the standard that should be met. While WCAG 2.1 Level AA was released more than two years before the publishing of this article, the US government is firmly entrenched in 2.0 as the standard for Section 508. Many organizations think of 2.1 as “The EU standard” — but this is simply not the case. These figures come from Usablenet’s incredibly useful every-six-month report on web accessibility litigation that was updated today.
Less than one-half of one percent of users use screen readers to navigate software. And those are largely the people who are currently suing for lack of accessibility. It is clear, however, that the lawyers who are making quite a bit of money off this litigation are always on the lookout for fresh meat. In the past year, they’ve added whistleblower suits, suits over digital trespass, suits over gift cards without Braille, and suits against over 100 sites using overlays and plugins. These all represent new avenues for litigators to attempt to continue their cash flow, as more organizations get fundamental accessibility religion for run-of-the-mill websites.
There are WAY more users who need magnification than those who need screen readers. Magnification is used by people with any level of vision loss for any reason. If you wear glasses, generally you can benefit from magnifying things, especially as you get older. That is a whopping 75 % of the country — people who wear glasses, people who wear contacts, and people who have had some type of permanent vision correction surgery.
WCAG 2.1 Level AA has two standards concerning magnification. The first one has been around for 11 years. The second is “new” (i.e., two years old) with WCAG 2.1.
SC 1.4.4 (Level AA) Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA)
and
SC 1.4.10 (Level AA) Reflow: Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:
Vertical scrolling content at a width equivalent to 320 CSS pixels, which is equal to a starting viewport width of 1280 CSS pixels wide at 400% zoom
Horizontal scrolling content at a height equivalent to 256 CSS pixels, which is equal to a starting viewport height of 1024 CSS pixels at 400% zoom.
Exemptions are available for images, maps, diagrams, videos, games, presentations, data tables, and interfaces, where it is necessary to keep toolbars in view while manipulating content, are exempt. That exemption list is not as long as it sounds. Most static and dynamic pages do not qualify.
Hmmm absolute pixel values that a developer / designer can define in CSS to get the optimal user experience — what does that sound like?
Oh yeah, RESPONSIVE BREAKPOINTS!
The guideline is called Reflow because the requirement is that the design re-organizes itself when someone zooms in up to 4X. But in actuality, it would have been more accurate to call it Responsive, because the way to implement that is *exactly* how you would implement responsive breakpoints.
— make it bigger
— re-organize the elements around the larger font sizes
— don’t make it hard for people to get around
By the way, if you are meeting the new guideline 1.4.10, you are probably inherently meeting 1.4.4
These are Level AA guidelines. I’ve heard people refer to Level AA as “nice to have.” They aren’t. Unless your company is in Ontario Canada only for Ontarians and is shutting down in five months, if there is an accessibility law, Level AA is required. Level AA is not as crucial as Level A, because Level A issues are blockers. That doesn’t mean Level AA isn’t essential!
1.4.4 and 1.4.10 are the guidelines that most likely trigger whining about how expensive being accessible is. Well, sure accessibility is going to be costly if you are doing it reactively (i.e., if you are trying to jam it in after all your design and development work is done). The vast majority of accessibility fixes are simple; five lines of code or less. Magnification fixes do not come in the “simple” category. Proactive accessibility where you design and code your digital property to be accessible; is a less expensive approach that results in a better product with fewer bugs that will more likely hit your release dates. Starting with an accessible design system like Clarity will help save you time. Don’t reinvent the wheel if you don’t have to.
Be proactive, be responsive, be inclusive, and you drastically reduce your risk of getting sued. You can view this as doing the right thing, or you can view this as not wanting to be the next notch on a litigator’s belt. I don’t particularly care why people decide to become accessible. I just care that they do it.
