Tag: accessibility testing

  • GitHub Adds Accessibility Improvements for Developers With Disabilities

    GitHub Adds Accessibility Improvements for Developers With Disabilities

    GitHub today revealed it added several capabilities to make it easier for developers with disabilities to access its code repository platform. The new capabilities were announced to coincide with Global Accessibility Awareness Day.

    Capabilities highlighted include a navigation tool and a search tool that can be used with a screen reader that GitHub provides.

    In addition, GitHub’s contribution graph has been updated to remove barriers for keyboard-only and screen reader users.

    Finally, GitHub has made site-wide color contrast improvements to the light and dark themes presented by Primer, the GitHub Design System.

    Ed Summers, head of accessibility for GitHub, said there are more than 1.3 billion individuals with a wide variety of disabilities that could, with access to the right tools, write code. That community today, however, is underrepresented as a percentage of the larger IT community, he noted.

    However, as tools such as GitHub Copilot—a generative artificial intelligence (AI) tool that helps developers write better, more secure code—is paired with GitHub Copilot Voice—a speech interface for GitHub Copilot that is available in technical preview—the GitHub platform becomes more accessible to developers with disabilities, he said.

    Generative AI coupled with a speech interface that eliminates the need for a keyboard is lowering the barrier for entry for every potential developer. But for individuals with disabilities, it represents a tremendous advance, noted Summers. Anyone who understands how code should be constructed can build an application, he added.

    It’s not clear what impact generative AI will have on the global shortage of developer talent that has persisted for decades but it’s clear the pace at which applications can be developed is about to dramatically increase. In addition, many organizations have embraced working from home in the wake of the COVID-19 pandemic. That shift makes it easier for many individuals with disabilities to become part of the workforce because they no longer need to commute to an office.

    Generative AI platforms are fundamentally changing the way humans interact with machines. Instead of requiring a developer to create a level of abstraction to communicate with a machine, it’s now possible for machines to understand the language humans use to communicate with each other. Via a natural language interface, developers will soon be asking generative AI platforms to not only surface suggestions but also debug applications and write the code used to create an application.

    At this point, like it or not, the generative AI genie is out of the proverbial bottle. Just about every job function imaginable will be impacted to varying degrees. In the case of DevOps teams, the ultimate impact should involve less drudgery as many of the manual tasks that conspire to make managing DevOps workflows tedious are eliminated.

    It may be a while before the impact of generative AI is fully appreciated, and there will certainly be more advances to come that will be applicable to individuals with disabilities. In the meantime, however, many members of a DevOps team may not even realize a member of the team has a disability as the writing of code continues to be increasingly automated.

  • 4 Ways to Build With an Accessibility-First Mindset

    4 Ways to Build With an Accessibility-First Mindset

    Over 1.3 billion people live with some form of disability. This accounts for almost 20% of today’s workforce in the U.S. While great strides have been made in closing the disability inclusion gap in the workforce, more needs to be done. 

    As the popularity of hybrid and remote work continues to grow, workers who live with a disability and work from home increasingly need accessible collaboration tools made available to them. 

    To meet this demand, developers need to build with accessibility in mind. By doing so, they can create more accessible software to help workers with disabilities overcome any unique challenges they may find when interacting with technology while creating an enjoyable working environment for everyone. 

    There are many ways to do this, however, here are some best practices and key learnings to help developers build with an accessibility-first mindset. 

    Challenge the Status Quo

    Innovation is always about challenging the norm, and this is especially the case when it comes to developing more equitable products. There are many ways to do this, depending on what processes are already in place. Still, one area that I believe can always be adapted is the way accessibility is thought of and managed internally, especially with regard to product design. 

    While the vast majority of companies today prioritize accessibility in some way or another, often it’s done by having a team—or, in the case of smaller departments, an ambassador—tasked with managing this work. This approach often leads to accessibility being seen as an add-on to design, something that happens at the end of the process. In reality, it’s better for developers and DevOps teams to take a hub-and-spoke approach to accessibility. In this model, there is one central source of expertise that people can go to for advice, but individual teams also are tasked with working on and being mindful of accessibility at the same time. The results as a collective would be far more collaborative and impactful. 

    Likewise, challenging the status quo could be as simple as encouraging conversations about accessibility with your team. If accessibility is a subject you want to discuss with your team but don’t know how to bring it up, remember that most accessibility problems stem from a lack of awareness. It’s usually an oversight, and ideas begin to flow once the conversation starts. So why not kickstart the conversation? Come prepared with user stories and potential solutions and your team will immediately start seeing all the appropriate changes that need to be made.

    Work Directly With People With Disabilities 

    When building any software, it’s important to gather feedback from all kinds of people so you can be sure you’re building the features and experiences people need. 

    When we begin a project or an update, we strive to understand how current functions or other similar products are (or are not) accessible so we can better understand our customers’ expectations or frustrations. There are a number of ways to do this, but perhaps the most broadly impactful is hiring people with disabilities and having an open discussion with them about the product. Along with hiring, it’s also valuable to contract specific companies that employ people with disabilities to test products and give their feedback. 

    Receiving this feedback is key to developing a successful product and usually results in a more flexible and well-rounded user experience. For example, a text-based app with extensive text scalability designed for people who are blind or low-vision will be equally as useful to a user who prefers their text to be small or uses the product in a language requiring different string lengths. Similarly, captions designed for people who are deaf or hard of hearing can be useful to anyone who might be in a noisy environment or who prefers to consume written rather than audio content. When you make a product work really well for a particular group, you inherently create a better and more adaptable experience for everyone; you are meeting users where they are. 

    Don’t Make Assumptions

    It’s incredibly important when you’re having conversations with people with disabilities or when designing a new product to not make assumptions. For example, early in my career, I would have assumed that an image-based program would be completely uninteresting to someone who is blind; I now understand that is categorically not true. By integrating interesting and vivid descriptions of images into the product, an image-based program can become accessible and engaging to all. 

    By avoiding assumptions about what someone can or cannot do based on their abilities, we open ourselves up to a world of creative solutions and possibilities that we might have otherwise not considered.

    While people with disabilities ultimately provide the best feedback, don’t forget to spend time on your own or as a team actively challenging your design and looking for ways to improve its accessibility. Spend an hour or two as a team using your product with a screen reader such as VoiceOver or TalkBack or use your application using only the keyboard but no mouse. By constantly engaging with and testing your own design, you will better understand the user experience and may catch bugs or accessibility issues on your own.

    Be Prepared for Trial and Error and Share What you Learn

    Twelve years ago when I first started to focus on prioritizing developing for accessibility, there was very little documentation on accessibility in this space–especially when designing for mobile technology. This caused a great deal of frustration and often slowed our work down as we tried (and failed) to get it right. Sometimes this involves a delicate balance of adhering to your product’s established standards (i.e. how things should be labeled or how things should look) while solving for accessibility and efficiency in tandem.

    Since then, things have changed a lot in the developer space. Today, there is a lot more material out there about the topic as well as industry standards to abide by. Universities are now offering more accessibility training within computer science courses, content creators with disabilities share more of their experiences, and companies are more open about sharing accessibility resources. 

    However, trial and error is still vital to building with an accessibility-first mindset, especially as we continue to innovate in this sector. So be patient and trust the process. 

    Inclusive design results in better products for everyone and, in particular, for all the people around the world experiencing some form of disability. Make sure you are a part of the solution and share your learnings with your developer community to continue this movement. 

    As a developer, the more time you spend learning and listening to your community and making them your number-one resource the more understanding you will be of their needs and how you can create the ultimate user experience. In turn, this empowers users to do their best work regardless of their abilities or circumstances. 

  • Applause Report Surfaces Functional Testing Issues

    Applause Report Surfaces Functional Testing Issues

    An analysis of more than 340,000 bugs collected by Applause, a provider of a testing platform designed to integrate with a range of DevOps platforms, found functional bugs accounted for 68% of issues. The research gathered data from 13,000 mobile devices and 1,000 unique desktops running 500 versions of operating systems and found that the majority of issues could be traced to functional bugs compared to visual (17%), content (9%), crashes (4%) and lags and latency (2%) issues that, collectively, only add up to 32%, the report found.

    The report also found screen readers comprised 66% of all accessibility bugs compared to keyboard navigation issues and insufficient color contrast which accounted for only 12%. In terms of localization, poor and missing translations account for more than two-thirds (67%) of bugs, the report found. Based on ongoing feedback data that Applause also continuously collects from customers, nearly half of organizations (47%) identified currency and number formatting as the most valuable bugs to identify when it came to localization.

    Overall, organizations ranked the discovery of crashes (75%), functional bugs (61%) and lag and latency issues (53%) as exceptionally valuable, according to Applause.

    Luke Damien, chief growth officer for Applause, said when it comes to testing, in general, there is still not enough focus on user and customer journeys. That lack of focus is becoming a larger issue as more organizations invest in digital business transformation initiatives that are driven largely by mobile applications, he noted. Payments are especially problematic because they often rely on application programming interfaces (APIs) exposed by a third party in a way that results in suboptimal application experiences that have a direct impact on revenues, he added.

    The challenge is that it’s not entirely clear how far left responsibility for application testing is shifting. In some cases, developers are assuming responsibility. In other cases, a dedicated testing team is still responsible. Developers, of course, will test applications as they build them but application experiences on a local machine may not always be replicated in a production environment. The issue is that most end users today are not especially forgiving when a mobile application fails to meet expectations. Months of development effort can be wasted simply because a function was not tested in a production environment.

    Less clear is to what degree testing will be automated in the future. Machine learning algorithms are making it possible to automate testing of both functions and user interfaces. It’s not likely the need for humans to be involved in testing will be eliminated any time soon, but many of the routine tedious tasks that conspire to limit the rate at which applications can be tested should be sharply reduced in the months and years ahead.

    In the meantime, an organization’s entire brand reputation is now tied to the quality of the application experience it enables on a mobile device. Revenue targets can now be easily missed if users of a mobile device choose one application over another simply because a function was broken—even for a short amount of time. As such, testing has never been more critical given organizations’ dependency on software.

  • mabl Makes Move to Automate Accessibility Testing

    mabl Makes Move to Automate Accessibility Testing

    mabl today made available in beta an automated accessibility testing capability that it added to its software-as-a-service (SaaS) platform for testing applications.

    Dan Belcher, mabl co-founder, said given the increased accessibility requirements included in various compliance mandates, there is a greater need to address these issues as early as possible in the application development life cycle. Otherwise, organizations could find they are liable for failing to comply with accessibility requirements outlined in, for example, versions 2.0 and 2.1 of the Web Content Accessibility Guidelines (WCAG).

    At the same time, providers of applications that don’t address accessibility are also likely to find themselves called out on public social media forums, noted Belcher. The damage to brand reputation can be considerable, he added.

    The SaaS platform mabl created makes it possible to create reusable tests using a low-code engine dubbed axe-core. Those tests can then be inserted, as appropriate, into a DevOps workflow. That approach allows a dedicated testing team to create tests in a way that doesn’t need to occur on a DevOps platform, said Belcher.

    Regardless of regulatory requirements, Belcher said there is a clear need to include end users with disabilities within a digital universe that continues to rapidly expand. Unfortunately, as a whole, the software industry is only just starting to make accessibility a first-class concern, he added.

    The goal should be to enable fast feedback via accessibility regression tests that address, for example, contrast check, said Belcher. However, it’s not likely those tests are going to eliminate the need for periodic audits by accessibility subject matter experts as an application continues to evolve, he noted. Those reviews would address everything from the user interface to the overall performance impact, noted Belcher. It may possible, however, to one day address 50% of the accessibility issues identified in the WCAG guidelines via automation, he noted. Scanning code as it is being developed will prevent a backlog and a buildup of accessibility debt that would be much more costly to address after an application is deployed, added Belcher.

    In general, Belcher said, it’s not likely automation is ever going to entirely eliminate the need for dedicated testing teams. Testing platforms such as mabl are designed to enable a finite testing resource to keep pace with an accelerated rate of application development, he added.

    Accessibility is, for all intents and purposes, a subset of any comprehensive software quality review. The sooner development teams realize that fact the less likely they will find themselves apologizing in the future for not coming to that realization earlier.

  • 5 Ways to Embed Accessibility in Your SDLC

    5 Ways to Embed Accessibility in Your SDLC

    Developing an accessible software development life cycle (SDLC) requires a commitment to inclusion from everyone at the beginning of every project. By committing to developing accessible products, you will avoid costly and timely remediation prior to deployment at the end of your product roadmap.

    Creating An Accessible Software Development Life Cycle (SDLC)

    An accessible SDLC is one in which accessibility is integrated into every stage from planning through maintenance. This includes accessibility policy, automated testing against that policy, incorporation into your QA processes as well as verifying and documenting conformance requirements such as voluntary product accessibility template (VPAT) creation.

    Integrating accessibility isn’t really all that different from testing for any other quality standard, like cross-browser compatibility or other bugs. Here are the five key elements required to support your efforts:

    Policy – Start by establishing your accessibility goals, then prioritize based on importance (which is helpful for future sprint planning). Define these goals and priorities in your policies so that you can use them to measure your successes and understand where you need improvements.

    Automated and Manual Testing – Automated testing works by using software to scan your digital assets—whether in production, dev or staging—with an accessibility rules engine to check for errors. It can quickly and efficiently catch machine-detectable web content accessibility guidelines (WCAG) failures—the accessibility standard—that engineers can fix during the development process. Automated testing can be performed in many ways; however, the approach that will work best for you will depend on the level of integration that your DevOps team can facilitate. Manual assessments are far more comprehensive than automated scans. They also take essential user experiences into consideration, and they can catch errors far beyond what is machine-detectable today.

    Integrated User Story Development or Continuous Integration/ Continuous Deployment (CI/CD) – Once you’ve found the failures, what do you do with them? They should be treated like any other bug or glitch that prevents customers from accessing or using your website or application. You’ll want to capture this information in your ticket tracking system. Many organizations use agile sprints and project management software to create tickets, which are then fed into the development pipeline and prioritized, assigned and completed. Finding a solution that will let you easily convert WCAG failures into user stories (either manually or, better yet, through automation) is key for feeding a prioritized pipeline of work to be done.

    Knowledge and Resources – There are specific development techniques used to solve accessibility failures. Without access to a comprehensive library of accessible code techniques, developers will spend a lot of time scouring the web for solutions. Yes, you can find good solutions if you look long enough, but even so, how do you know whether that solution is legitimate or optimal for your case? Having the relevant solutions for an issue at your fingertips (negating the need to do a ton of online research) lets your DevOps team work more smoothly with fewer disruptions.

    Accountability – Accessibility analytics establish accountability. How effective are your DevOps teams at reducing WCAG failures? Tracking failures across your digital properties on a defined cadence lets you see and document trends over time. You can also track activities like the volume of tickets that are tagged as accessibility remediation or bugs, or new features or capabilities to represent active efforts.

    Whether you’re on a small or large development team at any size organization, adopting an accessible SDLC by implementing continuous accessibility checks at each phase of your development cycle is the most efficient and effective strategy to ensure that your website or applications are WCAG and ADA conformant.

  • Three Manual Accessibility Testing Pain Points

    Three Manual Accessibility Testing Pain Points

    According to industry research, the vast majority of IT leaders view test automation as the single most important factor in accelerating software innovation. This also applies to automated accessibility testing – a great first step for making websites accessible to persons with disabilities. The new breed of automated tools can catch nearly 83% of all accessibility issues (not to be confused with overlays, which claim 100% automatic compliance.)

    Automation does not, however, replace the need for manual testing, which is the only surefire way to ensure all users can access the information on your website without difficulty. To get complete coverage, you also need to perform manual accessibility testing (which requires a human to complete using the various assistive technologies that people with disabilities depend on) with multiple browsers and interfaces. However, manual testing comes with several challenges, which is why testers often perceive it as painful or complicated.

    Pain Point One – WCAG Has Many Success Criteria

    The most widely-accepted set of accessibility standards are the Web Content Accessibility Guidelines (WCAG), created by the W3C. WCAG criteria are classified by various versions and levels. Versions include WCAG 1.0, 2.0, and most recently 2.1, with version 3.0 actively under development. Success criteria under each of these versions are further broken down into conformance levels A, AA and AAA, with each level adding criteria.

    Depending on which WCAG conformance level you choose, you could reasonably expect to check somewhere between 25 to 50 success criteria when assessing the accessibility of your site or app. As you can see, a significant amount of familiarity and expertise is required with WCAG success criteria to be able to perform accurate, full-coverage accessibility testing on a site or app.

    Fortunately, software has reached the point in testing maturity where there are guided instructions for testing for specific criteria that must be manually tested. One example is keyboard navigation, often used by persons with motor disabilities. In this instance, the tool would simulate a user who interacts with a web page solely by using their keyboard; then the tool would describe a step-by-step instruction to identify accessibility issues during keyboard navigation. One such example: a news site with a carousel featuring five news stories, only one of which is visible at a time. There needs to be ‘previous’ and ‘next’ buttons that can be accessed and triggered using a keyboard so that keyboard users can navigate through the stories just as easily as they could with a mouse.

    Pain Point Two – Screen Readers Take Time and Expertise to Learn

    In addition to understanding numerous success criteria, accessibility testers also need to understand how to use a screen reader, a popular form of assistive technology. There are numerous screen readers available including JAWS, NVDA, VoiceOver and Talkback. Now, imagine having to memorize more than 50 success criteria that need to be tested across three different screen readers in multiple testing environments (desktop, responsive web, native mobile, etc.).

    Luckily, customized testing methodologies have been developed based on a chosen ruleset and testing environment. This reduces the amount of memorization and prior experience the tester needs to run effective tests. With specific screen reader testing steps outlined for each ruleset and testing environment, accessibility teams can improve their efficiency and create a standardized testing process for the whole testing team to follow—whether they are screen reader experts or not—resulting in a significant productivity boost.

    Pain Point Three – WCAG Success Criteria Can Be Open to Interpretation

    Some WCAG success criteria can be very contextual. Criteria that appear simple to test for, like color contrast requirements, can sometimes be tricky to analyze. For example, imagine a black, bold-faced word featuring dark gray shadowing against a light gray website background.

    In this image, which two colors should be compared to verify whether the minimum color contrast requirements are satisfied? Light gray and black, dark gray and black or light gray and dark gray?

    In scenarios like this, different accessibility experts can (and will) have different opinions. For a developer, there is nothing more frustrating than receiving different remediation requirements for the same issue. This can create confusion and introduce significant delays in the release of a product.

    The solution is clearly documented and detailed requirements to help reduce the potential number of issues that can be interpreted differently. Properly documented testing processes can help ensure that the results coming from an accessibility test team will be consistent, and significant time will be saved communicating issues back and forth between testers and developers.

    Automated testing is great for addressing many ‘low-hanging fruit’ problems without having to be an accessibility expert or hire one, but it does not eradicate the need for manual testing. While there are certain characteristics of manual testing that can make it onerous, fortunately, there are guided testing tools, auditors, methodologies and more available to take the pressure off accessibility teams. This will enable development teams to strike the ideal composition of manual and automated accessibility testing that helps them identify and repair the highest possible number of issues.

  • Embedding Accessibility into the DevOps Process

    Embedding Accessibility into the DevOps Process

    Calls for accessibility and inclusion are a defining characteristic of current times. Persons with disabilities (PwD), including vision, hearing, cognitive and physical impairments and others, are demanding equal access to virtually all public services and forums they interact with, from transportation to banking and self-service terminals in airports—and increasingly, digital (web and mobile) services.

    Ensuring accessibility can help enhance brands and is good business practice. The process can seem daunting but integrating accessibility into DevOps doesn’t have to be overwhelming. There are several simple steps for getting started.

    Understanding Your Organization’s Unique Accessibility Motivators

    Knowing what accessibility elements you need to test for depends on numerous factors, including your industry and where you are located.  For example, U.S. government organizations are subject to Section 508, while telecommunications providers must comply with the Communications and Video Accessibility Act (CVAA). Different scenarios require a nuanced approach to accessibility testing.

    The risks of digital inaccessibility are growing far beyond government websites, with the number of Americans with Disabilities Act (ADA)-based web accessibility lawsuits increasing 181% between 2017 and 2018. Since the beginning of this year alone, several well-known brands including Domino’s Pizza and Beyoncé have been sued for web accessibility breaches, bringing the issue to the forefront.

    E-commerce sites are often more concerned with lost revenue opportunities, as the average blind person is known to abandon several companies per month due to web inaccessibility. For transaction-oriented sites, inaccessibility translates directly to lost business. Whatever the motivators, building empathy can be a great way to give this mission meaning for developers. Organizations can do this by staging and having developers participate in “empathy events” where simulations are offered and developers can experience first-hand what it’s like to interact with a given website using the same assistive technologies that people with disabilities rely on regularly.

    Set Achievable Interim Milestones

    Agile DevOps teams emphasize catching defects as early as possible in the software life cycle to ensure efficient, high-quality rollouts. Unfortunately, accessibility testing is often relegated to the end of the process or performed as user-acceptance or usability testing. This type of testing is often manual and can be resource-intensive and expensive.

    Chart showing the process for building in accessibility into a product

    Organizations only became aware of issues upon hearing from end users encountering problems—or, worse, taking legal action to gain equal access to web-based content and services.

    Getting from a manual process to a fully automated and integrated process takes time. We recommend setting achievable, interim milestones that start small and build on early success. Organizations may not know what to tackle first, but some commonly shared examples of achievable first milestones are accompanying all digital videos with subtitles and/or sign language translation (for the hearing impaired) and ensuring that all new UIs are clear of any issues identified by automated tools. Experts and trainers can offer valuable advice on addressing the basics and then building on the success.

    Implement Tools

    Today’s developers have easier access to more comprehensive accessibility testing tools than ever before. Currently there are tools available for all the major platforms (web, Windows, Android and iOS) and many of these have been open-sourced, making them richer every day. Interactive testing functionality can enable development teams to thoroughly assess the accessibility of products early on in the cycle, while libraries allow these tests to be run regularly as part of the development test automation. A good tool will provide developers with simple remediation guidance and allow them to embark on a learning journey to increase their knowledge and expertise.

    Measure, Improve and Automate

    Ongoing measurement is the key to understanding whether your accessibility transformation is taking hold. Leading metrics will focus on the change in development practices. These changes will give early indication of end user outcomes. An example of a leading metric is “percentage of new UI code that is clean from an automated testing perspective.”

    End user outcomes, while lagging, are important to ensure that the activity is leading to real change. An example of an outcome might be the number and the change in the accessibility-related call center inquiries. A reduction would indicate that fewer accessibility issues are making their way into production. Metrics are strongest when they are presented in a manner that directly correlates to business outcomes (such as customer satisfaction), as these tend to resonate the most with business executives, which helps build the broadest internal support base.

    Once you’ve had some early successes, it’s time to expand, and you can keep tackling issues incrementally. Organizations should also focus on continually shifting accessibility testing “further left” earlier in the development cycle to enhance quality while maintaining velocity. The sooner you detect and fix accessibility issues, the less likely these are to become more deeply baked into the software, making them more difficult and time-consuming to undo.

     chart showing building in accessibility earlier in the product development cycle

    Organizations also should consider replacing interactive and manual accessibility tests with fully automated tests. While manual testing cannot be completely eliminated, automated unit testing and integration testing enable developers to test for accessibility as they code (not after the fact), while automated regression testing ensures live web content and applications stay accessible after changes are made. Automated regression testing is critical for organizations wishing to ship software often while maintaining quality—in some industries such as financial services, a disproportionate number of websites have experienced some level of accessibility regression.

    Conclusion

    DevOps teams are focused extensively on maintaining exceptionally high levels of software quality combined with velocity. We’ve become obsessed with minimizing the number of bugs that make it into production but may be overlooking one of the key attributes of high-quality software—accessibility.

    In most cases, functional testing does not cover accessibility testing. While functional testing determines whether a system is working as expected (i.e., certain inputs generate certain outputs), accessibility focuses on ensuring usability for PwDs as a non-functional attribute. With estimates that the current number of PwDs in the U.S. nearly equals the total populations of California and New York combined, accessibility testing needs to be prioritized in the same way as functional testing. Otherwise, you are shutting these people out.

    In summary, organizations that demonstrate a commitment to accessibility through their digital products and services will have a natural advantage in an increasingly competitive market space. Getting started can be relatively simple, and you should focus on motivating development teams to achieve and overachieve, emphasizing continual improvement rather than perfection from the get-go.

    — Dylan Barrell