DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • DevOps Chats
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Communities
    • AWS Community Hub
    • CloudBees
    • IT as Code
    • Rocket on DevOps.com
    • Traceable on DevOps.com
    • Quali on DevOps.com
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Digital Anarchist
  • Media Kit
  • About
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DevSecOps
  • Leadership Suite
  • Practices
  • ROELBOB
  • Low-Code/No-Code
  • IT as Code
  • More
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps

Home » Blogs » DevOps Practice » Accessibility and Feature Flags

accessibility

Accessibility and Feature Flags

By: Heidi Waterhouse on November 10, 2020 1 Comment

Being able-bodied is a temporary condition. Some of us are born with disabilities, and some of us develop them. At some point in your life, you will get old enough to need reading glasses, or you will break your arm, or you will develop hearing problems. Are you reading this page through glasses? Are you using a wrist brace or ergonomic mouse? Is your operating system set to dark mode? Those are all accessibility modifications.

Related Posts
  • Accessibility and Feature Flags
  • IBM launches Equal Access Toolkit to help developers build accessible websites and applications
  • Three Manual Accessibility Testing Pain Points
    Related Categories
  • Blogs
  • DevOps Practice
    Related Topics
  • application development
  • disability
  • feature flags
Show more
Show less

The Web Was Born Accessible

One of the things I love and appreciate about the world wide web’s governing body, W3C, is that they are constantly working to make and keep the web open and accessible. The standards that browsers and other software use are derived from the W3C recommendations. Your current browser can serve pages from 1998 and they are perfectly legible, and even pretty, if the images were captured.

DevOps Connect:DevSecOps @ RSAC 2022

The W3C has a group dedicated to accessibility, and their new set of standards, WCAG 2.2, will take effect this month. In December, a website’s accessibility will be rated based on the new standards.

> WCAG 2.0 and WCAG 2.1 are stable, referenceable technical standards. They have 12 to 13 guidelines that are organized under four principles: perceivable, operable, understandable and robust. For each guideline, there are testable success criteria, which are at three levels: A, AA and AAA.

There are lots of easy accessibility fixes for web pages, such as using semantic headings instead of text styling and using HTML buttons instead of DIVs. Many times, however, even the lowest level, A, is missing from an organization’s web pages. But like everything in software, progressive improvement and rapid feedback are more useful than a large transformation project that requires a massive commitment.

Some Web Accessibility Needs Conflict

Sometimes, accessibility needs conflict. For example, in the example users listing in the WCAG documentation, some of the users need their text to reflow around increased-size buttons and some users need the buttons to stay in a stable location for findability. If you’ve ever been frustrated when a phone update reorganizes all your apps, you can identify with how difficult it can be when an everyday interface changes without permission.

Low-vision users are often helped by high-contrast text, black-on-white or white-on-black. However, users with dyslexia and other text-processing disabilities can find the contrast too jarring and need a lower contrast to help them read comfortably—something like dark grey on off-white. It’s difficult for a site or application to meet those conflicting needs, so users often have browser extensions or settings that help them manage their web experience.

Site and application developers need to be aware that not everyone is using their site or app exactly the way the developer sees it. Users may have smaller screens, or be on a mobile device, or have installed browser extensions the developer has never heard of or imagined. This system works as long as we develop according to the accessibility standards that keep the web semantic. It seems contradictory that making the web accessible to machines helps humans, but it does because the humans are using the computer’s concepts to translate information in a way that works for them.

How Feature Flags Can Help

I’ve been thinking about how feature flags could make designing for accessibility easier, especially around the problem of trying to serve populations with different needs.

When it is possible to serve everyone, that should be the default and the main page code. Everyone is served by standards such as semantic headings, image alt text and text that is not an image. Some people need further accommodations, such as reduced motion, tab navigation or large buttons. Those needs could be flag variants.

In the image below, I have configured a flag with four variations for text display:

  • Standard (no changes to CSS behavior)
  • Low-vision (high contrast text, allow resizing)
  • Dyslexia (use OpenDyslexia font in CSS)
  • Reduced contrast (Reduce the contrast between text and background)

This flag variation could be tied to a user-configurable setting so that every time they logged into the site, they would get the text the way they need it, even if they were on a different browser or device.

That’s a simple example, of course. Ideally, developers and accessibility advocates would work together to determine which part of the site or app should be modified, and how it would work in combination with other modifications.

Lack of Planning Is Technical Debt

Even if your team doesn’t have user research or accessibility experts available all the time, you can code proactively to make room for them. Accessibility flags would be permanent—you wouldn’t want to remove them as you would a rollout flag. Since they are permanent, there is no harm in using them as a placeholder; they won’t add more testing demand empty than they will full.

At the start of a project, most teams don’t have the resources to do everything they want, even though they know it will need to be done eventually. We don’t do localization for proof-of-concept applications, we don’t write API documentation for strictly internal tools. But if a product succeeds, then we do need to add those elements and they become technical debt that we have to pay off without adding new value to the product.

One of the ways to reduce the cost of this debt is to add placeholders for future modifications. Trying to refactor an application with hard-coded interface elements to accept localization is like trying to add chocolate chips to cookies that are already baked—it’s much less effective. Using flags set to only return a default value (for now) is a way to plan for future changes in your code, without making the full investment.

The Future Is Here

The WCAG standards are not arbitrary or imposed without meaning. They exist to help everyone access the information, services and capacity they need. When we build sites that don’t meet those standards, we are losing customers, clients and users—and not in small numbers.

Using feature flags to make your site accessible is a smaller, cheaper intervention than creating entirely separate sites. Feature flags also help build the framework to provide other elements of your site on an on-demand basis, allowing you to meet user needs with precision and efficiency.

Filed Under: Blogs, DevOps Practice Tagged With: application development, disability, feature flags

Sponsored Content
Featured eBook
DevOps: Mastering the Human Element

DevOps: Mastering the Human Element

While building constructive culture, engaging workers individually and helping staff avoid burnout have always been organizationally demanding, they are intensified by the continuous, always-on notion of DevOps.  When we think of work burnout, we often think of grueling workloads and deadline pressures. But it also has to do with mismatched ... Read More
« Achieve Cloud Resilience Through Systematic (and Chaotic) Testing
Applause Labs Prototypes New Initiatives to Improve the Tester Experience »

TechStrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

Deploying Microservices With Pulumi & AWS Lambda
Tuesday, June 28, 2022 - 3:00 pm EDT
Boost Your Java/JavaScript Skills With a Multi-Experience Platform
Wednesday, June 29, 2022 - 3:30 pm EDT
Closing the Gap: Reducing Enterprise AppSec Risks Without Disrupting Deadlines
Thursday, June 30, 2022 - 11:00 am EDT

Latest from DevOps.com

Developer’s Guide to Web Application Security
June 24, 2022 | Anas Baig
Cloudflare Outage Outrage | Yet More FAA 5G Stupidity
June 23, 2022 | Richi Jennings
The Age of Software Supply Chain Disruption
June 23, 2022 | Bill Doerrfeld
Four Steps to Avoiding a Cloud Cost Incident
June 22, 2022 | Asim Razzaq
At Some Point, We’ve Shifted Too Far Left
June 22, 2022 | Don Macvittie

Get The Top Stories of the Week

  • View DevOps.com Privacy Policy
  • This field is for validation purposes and should be left unchanged.

Download Free eBook

The 101 of Continuous Software Delivery
New call-to-action

Most Read on DevOps.com

Survey Uncovers Depth of Open Source Software Insecurity
June 21, 2022 | Mike Vizard
One Year Out: What Biden’s EO Means for Software Devs
June 20, 2022 | Tim Mackey
Open Source Coder Tool Helps Devs Build Cloud Spaces
June 20, 2022 | Mike Vizard
Not Everything That is Necessary Adds Value
June 20, 2022 | Lance Knight
TechStrong Con: Downturn Brings Additional Sense of DevOps U...
June 21, 2022 | Mike Vizard

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2022 ·Techstrong Group, Inc.All rights reserved.