EU Think Tank
  • Home
  • Business
  • Leadership
  • Economics
  • Recruitment
  • Innovation
  • Strategy
  • More
    • Customer Experience
    • Managing People
    • Managing Yourself
    • Communication
    • Marketing
    • Organizational Culture
    • Technology
Featured Posts
    • Managing Yourself
    How to Recover from Work Stress, According to Science
    • July 6, 2022
    • Managing Yourself
    Reeling From a Sudden Job Loss? Here’s How to Start Healing.
    • July 6, 2022
    • Managing People
    Companies Must Be Robust in Six Key Areas to Cope with Uncertainty – SPONSOR CONTENT FROM ROLAND BERGER
    • July 6, 2022
    • Technology
    Build Better Management Systems to Put Your Data to Work
    • July 5, 2022
    • Economics
    How Businesses Can Hold Their Banks Accountable on Climate Change
    • July 5, 2022
Featured Categories
Business
View Posts
Communication
View Posts
Customer Experience
View Posts
Economics
View Posts
Green
View Posts
Health
View Posts
Hiring and Recruitment
View Posts
Innovation
View Posts
Leadership
View Posts
Managing People
View Posts
Managing Yourself
View Posts
Marketing
View Posts
Middle East
View Posts
News
View Posts
Organizational Culture
View Posts
Russia
View Posts
Saudi Arabia
View Posts
Strategy
View Posts
Technology
View Posts
Ukraine
View Posts
Uncategorized
View Posts
EU Think Tank EU Think Tank
7K
9K
4K
1K
EU Think Tank EU Think Tank
  • Home
  • Business
  • Leadership
  • Economics
  • Recruitment
  • Innovation
  • Strategy
  • More
    • Customer Experience
    • Managing People
    • Managing Yourself
    • Communication
    • Marketing
    • Organizational Culture
    • Technology
  • Technology

3 Strategies for Developing More-Accessible Software

  • June 1, 2022
  • euthinktank
Total
0
Shares
0
0
0

There is no single accessibility expert. It’s a shared responsibility, and all developers have to leverage others’ knowledge to grow their understanding and manifestation of accessibility. By that same token, the main accessible frameworks that developers use can’t be taken as all encompassing. In the same way that developers wouldn’t create a new feature using only one tool, they should have multiple inputs to guide them through accessibility. The more robust developers’ accessibility checkers are, the better they’ll serve people with diverse needs. The author presents three ways for developers to avoid falling back on inadequate accessibility tools and guidelines and keep up with the shifting threshold for accessibility.

The U.S. General Services Administration recently released its Equity Action Plan, specifying a focus on accessibility beyond the bare minimum for all digital government services. This move from a federal agency signals to businesses that they’ll need to follow suit and strive for accessibility that exceeds basic inclusive changes.

But going above the bare minimum demands a different mindset from developers. Many of the people who are tasked with re-envisioning the bar for accessibility rely too heavily on a small set of tools that give them tunnel vision when building. React, Vue, and Svelte all have accessibility baked into them, but developers who use only what comes off the shelf risk becoming too singularly focused. Many tools prioritize the visual elements of accessibility because they’re the most noticeable, but what about users with auditory or mobility issues?

In the same way that developers wouldn’t create a new feature using only one tool, they should have multiple inputs to guide them through accessibility. The more robust developers’ accessibility checkers are, the better they’ll serve people with diverse needs.

I’ve worked in development for nearly a decade and have spent the past two years striving to make tools that help software designers and developers instill accessibility into their craft. Here’s how developers can avoid falling back on inadequate accessibility tools and guidelines and keep up with the shifting threshold for accessibility.

Mix and match your accessibility tools.

Each development platform has its own set of accessibility guidelines and requirements. For example, the accessibility (a11y) standards for the web are detailed in the Web Content Accessibility Guidelines (WCAG), Apple uses Human Interface Guidelines (HIG), and Android has its own set of guidelines. Web libraries like React and Vue have sections on best practices for accessibility, as do component-specific libraries like React Select and Vue Select.

But if developers just follow the accessibility parameters of the platform they’re building in, they’ll inevitably leave some accessibility gaps unfilled. Using just one set of guidelines is like expecting a table of contents to tell you the whole story.

The best way to avoid this problem is to mix and match tools and guidelines. If your framework leans more toward visual navigation, pair it with Google’s accessibility tree or Firefox’s Accessibility Inspector, which help developers understand how content is exposed to assistive technology. If your requirements are predominantly for people with audial impairments, try Orca’s screen reader for desktops like MATE, GNOME, and Unity. The Sonar GNU/Linux project is great for accommodating users with visual difficulties

There’s also a wealth of tools that developers can utilize to test accessibility across platforms. Linters are great to check code, while a11y add-ons can support writing accessible components into Storybook.

The more tools you use in tandem with your primary platform’s accessibility requirements, the more complete your picture of accessibility is. The tools don’t have to be purely development tools either — discussions on Reddit’s Web Accessibility community, Stack Overflow, and Slack’s accessibility channel can point you to the places that your original guidelines don’t cover.

Learn from localized accessibility legislation.

Developers have to take a global mentality when building products, and in turn, they have to acknowledge that accessibility adherence changes based on location. Accessibility is much more than translating text and copy-pasting from a framework that worked elsewhere.

What may be legally compliant or inclusive in one country is likely different in another. For example, the Accessibility for Ontarians with Disabilities Act (AODA) doesn’t have the same specifications as the European Standard for Digital Accessibility (EN301 549). And these types of legislation tend to go beyond the scope of popular technical frameworks like React, so developers can’t create compliant products by exclusively referring to those frameworks. For instance, the EN301 549 states that biometrics cannot be used as the only means for user identification. However, the WCAG — a staple set of guidelines in tech — have no such mention of biometrics.

Some locations will inevitably have stricter rules around accessibility, and developers have to apply these standards in their products across the board, even in countries that don’t ask for them. The maximum accessibility requirements you encounter should be the minimum you incorporate throughout all your work. It’s not only a moral duty, but a smart business decision. At some point, regulations are going to evolve, and what’s seen as strict now will become the norm later. Invoking a number of tools to include a more broad spread of accessibility from day one will help prevent companies from spending time and money fixing problems retroactively.

Uncover grey areas of standalone frameworks via user testing.

There isn’t a completion certification for accessibility. The more products or features you introduce, the more you’ll have to test and the further you’ll have to go beyond the tools you’re using to monitor your accessibility. Even if you aren’t actively releasing, there is always room for improvement, particularly for more complex elements like keyboard usage, focus, and landmarks.

Reviewing accessibility requires much more than downloading whole libraries you deem accessible and building from them. The building blocks may be accessible, but that doesn’t guarantee the end product will be. Developers have a responsibility to test the product as they construct it on both a granular scale and in its entirety. It has to be put in context, in lived experiences to confirm that it really is accessible.

Developers should repeatedly trial products and features in person or remotely with a diverse group of users of varying capabilities, ages, and backgrounds. At Stark, we test in person where possible, but otherwise use Zoom to conduct feedback sessions, ensuring captions, sign language interpretation, and other user needs are met. Fable is a brilliant platform to engage people with disabilities for user research and to highlight testing methods that reveal the gray areas of standalone frameworks. For us, user testing showed that frameworks don’t stop developers from having an incorrectly set up focus order for keyboard users. We only learned by speaking with people who use keyboard navigation for websites.

There is no single accessibility expert. It’s a shared responsibility, and all developers have to leverage others’ knowledge to grow their understanding and manifestation of accessibility. By that same token, the main accessible frameworks that developers use can’t be taken as all encompassing. They have to be used alongside other tools and testing to keep up with — and keep pushing for — a higher accessibility bar.

Total
0
Shares
Share 0
Tweet 0
Pin it 0
You May Also Like
Read More
  • Technology

Build Better Management Systems to Put Your Data to Work

  • euthinktank
  • July 5, 2022
Read More
  • Technology

Monitoring Employees Makes Them More Likely to Break Rules

  • euthinktank
  • June 27, 2022
Read More
  • Technology

Dehumanization Is a Feature of Gig Work, Not a Bug

  • euthinktank
  • June 23, 2022
Read More
  • Technology

How AI Can Make Strategy More Human

  • euthinktank
  • June 22, 2022
Read More
  • Technology

Why Build in Web3

  • euthinktank
  • June 22, 2022
Read More
  • Technology

Building Transparency into AI Projects

  • euthinktank
  • June 20, 2022
Read More
  • Health
  • Innovation
  • News
  • Technology

The Global Mission to Tackle Cancer

  • Sam Tilston
  • June 14, 2022
Read More
  • Technology

Why You Need an AI Ethics Committee

  • euthinktank
  • June 14, 2022

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Featured Posts
  • 1
    How to Recover from Work Stress, According to Science
    • July 6, 2022
  • 2
    Reeling From a Sudden Job Loss? Here’s How to Start Healing.
    • July 6, 2022
  • Companies Must Be Robust in Six Key Areas to Cope with Uncertainty – SPONSOR CONTENT FROM ROLAND BERGER
    • July 6, 2022
  • 4
    Build Better Management Systems to Put Your Data to Work
    • July 5, 2022
  • 5
    How Businesses Can Hold Their Banks Accountable on Climate Change
    • July 5, 2022
Recent Posts
  • So You Haven’t Heard Back After a Job Interview…
    • July 5, 2022
  • What Makes a Great Executive Retreat
    • July 5, 2022
  • Adapt Your Digital Marketing Strategy to Post-Pandemic Consumer Behaviors – SPONSOR CONTENT FROM MICROSOFT
    • July 5, 2022

Sign Up for Our Newsletters

Subscribe now to our newsletter

EU Think Tank
  • Home
  • Privacy Policy
  • Guest Post
  • Contact

Input your search keywords and press Enter.