App Accessibility Testing finds accessibility issues early on in the mobile app development process so that developers can take a more proactive approach to fixing these issues.

It requires almost no setup, BrowserStack claims. Developers just need to upload their app and then they will have instant access to real iOS and Android devices.

The platform also includes an app workflow scanner that is based on BrowserStack’s rules engine. Through this scanner, developers can navigate through their app as a user and perform scans on selected screens. It also allows reported issues to be grouped by type and violated WCAG guidelines, which helps with prioritization. 

In addition, App Accessibility Testing offers one-click access to TalkBack and VoiceOver screen readers, including the ability to record or screenshot issues. According to the company, this “addresses the need for seamless integration with assistive technology, ensuring comprehensive testing without juggling multiple tools.”

It also features a centralized reporting dashboard with annotated screenshots to provide insights and action steps for fixing issues. Developers can search issues by name or owner, generate new reports, and easily share reports.

Other key benefits include support for WCAG 2.2, support for hybrid and cross-platform apps, local testing for apps behind a firewall or using a VPN, geolocation testing, and localization testing for screen readers.

“App Accessibility Testing reflects our commitment to digital inclusion,” said Nakul Aggarwal, CTO and co-founder of BrowserStack. “This frictionless solution empowers QA and developer teams to create truly inclusive apps, advancing our vision for accessible software across all platforms.”

The post BrowserStack is helping developers address mobile app accessibility with new solution appeared first on SD Times.

WCAG 2.2 adds nine new success criteria. The first three are related to keyboard focus. There is a minimum and enhanced version of Focus Not Obscured, which requires that when a “user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.” The other focus-related criteria is about the appearance that indicates when something is in focus. Now it must have an indicator that is at least a 2-pixel thick perimeter around the unfocused component, and must have a contrast ratio that is 3:1 between the focused and unfocused states. 

“So for a person that is using something like a keyboard or a switch control to control the computer because they have very limited motor movement, they need to be able to see the indicator of where the focus is to know that when they press enter, they’re pressing enter on the right thing,” said Glenda Sims, chief information accessibility officer at Deque Systems, a company that provides tools to help developers with accessibility efforts. 

Moving on, Dragging Movements requires that functionality that requires something to be dragged also be able to be completed without dragging. According to Dr. Lionel Wolberger, W3C voting member and COO of UserWay, this is especially helpful for people with tremors who cannot reliably place their mouse in a specific location of the screen. 

Sims added: “This one is highly motivated by motor disabilities. And dragging movements can be difficult for a person with a fine motor disability.”

The fifth new criteria in WCAG 2.2 sets a minimum size for targets to be at least 24 x 24 CSS pixels, with a few exceptions. According to Sims, this size will make it more likely that a human finger can actually touch the target and have a decent chance of hitting what they intended. “You know how hard it is to sometimes hit the right thing with your finger, and how you miss it, and trigger something you didn’t mean to trigger,” said Sims. 

The sixth new criteria is around websites being consistent in the way help can be accessed, which is beneficial for people with cognitive disabilities. “It helps everybody that the help for a given site can be found in a consistent location, and that it doesn’t keep jumping around,” said Wolberger.

The next one is Redundant Entry, which says that information that a user previously entered that needs to be reentered should be either auto-populated or available for selection. The exceptions to this are when re-entry is essential, security purposes, or the original information is no longer valid.

And the final two are another minimum and enhanced version of the same item: Accessible Authentication. This means that there should be an authentication method that isn’t reliant on a “cognitive function test” like remembering a password or solving a puzzle. 

Consistent help and accessible authentication are especially helpful for people with cognitive disabilities. “The cognitive accessibility piece is the next great frontier for accessibility,” said Sims. “If we count the number of humans that have neurodiverse needs that are locked out from digital independence right now, we’re going to make leaps forward as we really learn how to address cognitive.”

The post W3C publishes new version of its web accessibility standard, WCAG 2.2 appeared first on SD Times.

Accessibility is all about the user experience, and is especially important for users with disabilities. Automated end-to-end testing helps answer the question of how easy or difficult it is for users to engage with the software.

“If the software is crummy, if it’s not responding, you’re going to have a bad experience,” noted Arthur Hicken, technical evangelist at Parasoft.  “But let’s say the software has passed the steps of being well-designed and well-constructed. Hicken said, after that, come those accessibility tests, which are, is this really usable and well-suited for humans? And which tasks do humans use most?”

There is nothing innate about test automation that can raise a flag to any issues, unless the model is trained to identify and report, for instance, if any tasks take more than four steps to complete, it should be looked at.

According to Jonathan Wright of Keysight, it’s equally important to be sure the application is usable and accessible in various regional deployments involving different language sets and cultural variations. “I had a call with a large-scale organization and they wanted to know how we could support their multiple different localization deployments, which includes help and documentation. So it’s really the ability to support global rollouts that follow the sun.”

Wright said in large organizations, centers of enablement are being marginalized as self-service takes hold. “I’m in a large organization, what tools and technology do I need? And you know, it’s usually a people problem, not a technology problem. It’s kind of giving them the right tools to be able to help them do the job.”

For accessibility testing, mabl’s Fernando Mattos said companies often will have a different team to do that type of testing. “Many times, it’s a third-party company performing that, along with legal advice. What we’re trying to do is to shift that left and allow the reusability of you having already tested the whole UI. Why recreate all those tests in a separate tool, and why have a different team do it much later after deployment?”

The impact of a poor user experience on digital businesses can involve loss of customers and revenue as users today expect a seamless experience. “In e-commerce, in B-to-C commerce, they’re seeing hypercompetitiveness in the market and customer switching because the page takes a little too long to load,” he said. “And that talks a little bit more about what end-to-end testing is.”

Mattos added that making sure things are working properly has been seen as functional quality, but it’s important for organizations to make sure the performance of the application is fast, that it responds quickly, and the UI shows up quickly. He added that organizations can reuse their functional test cases to check for accessibility, so if a development team is pushing new features, and one introduces a critical accessibility issue that gets caught right at the commit or pull request phase, it can get fixed right away. Mabl, and the industry as a whole, is moving to shift this testing left, rather than performing it just prior to release.

Mattos noted that there are libraries for automated accessibility testing that can be used to catch 55% to 60% of the issues, while the remaining 40-45% of issues have to be done by people with the disability or experts that know how to test for it. But for the 55-60%, mabl pushes those into development and introduces accessibility testing there, instead of waiting for a third-party company or team to duplicate the test and catch an error a week later.

The post Accessibility testing appeared first on SD Times.

The plugin was developed by members of the accessibility and design teams at eBay and is released for public use on Figma.

The plugin can help an app designer select a frame for annotations, and then present a list of steps to ensure that the design meets accessibility standards. For instance, Include will create a list of images used in a mockup. The designer can mark an image as informative, and the plugin will prompt them to include alt text, which allows screen readers to describe the image.

There are also many additions to the plugin. One of them makes a copy of the design with text enlarged to 200%, so the designer can easily see where text may overflow, or where the design may break, which shows how the app might look for those who enlarge text on their devices. 

Other additions include functionalities for color contrast accessibility checks, methods for creating commonly-used layers and frames within the Figma document, and utility functions for working with Figma frames and strings.

Additional details on the project are available here.  

The post SD Times Open-Source Project of the Week: Include appeared first on SD Times.

It has launched the Inclusive Tech Lab, which is a successor to a lab that was created by the Xbox team. The purpose of the lab will be to “to learn and develop specifically for people with various types of disabilities.” Compared to the original lab, this one is larger and will be more equipped to bring in visitors who can participate in the product-making process. 

Though the lab will showcase Microsoft’s accessible hardware, software, and services, it will mostly serve as a design incubator for inclusive products. 

“It is a place designed to demonstrate what is possible when you intentionally and proactively include people with disabilities in the product-making process and strive to build products that are genuinely inclusive by design,” Dave Dame, director of accessibility at Microsoft, wrote in a blog post. 

The company also revealed new adaptive accessories for people who might have difficulty using a mouse and keyboard.

The adaptive accessories consist of three main components, an Adaptive Mouse, Adaptive Hub, and Adaptive Buttons. 

The Adaptive Mouse can be customized with the Microsoft Adaptive Mouse Tail and Thumb Support to make a unique mouse. The Thumb Support accessory also includes the ability to customize it to switch sides for left or right-handed users. 

The Adaptive Hub and Buttons can be used together to replace traditional keyboards. Options for button toppers include a d-pad, joystick, or dual button, or users can 3D print their own button topper to suit their specific need. 

These adaptive accessories will be officially launched in the fall. 

The post Microsoft launches new lab for building inclusive tech, unveils new adaptive accessories appeared first on SD Times.

Today’s digital work surely rivals the physical world – but not if you’re living with a disability. 

According to WebAIM (Web Accessibility In Mind), more than 97 percent of the one million pages it evaluated in 2021 had WCAG 2 (Web Content Accessibility Guidelines) failures. However, it’s not as if designers and engineers don’t care about accessibility – they do. In an Applause study in 2021, nearly 70 percent of respondents agreed that their companies were prioritizing digital accessibility. 

So what’s happening? In order for digital experiences to be accessible to everyone, inclusive design must start with the software development cycle. It’s not something that can be added or designed for after the fact. Modern software development — like so much else in our post-pandemic worlds — must begin with empathy. 

Designing with empathy 

In principle, every software development project should start with considering the broadest range of people. Ensuring accessible digital experiences requires an ongoing commitment to designing inclusive experiences, writing code with accessibility in mind, and testing digital properties for key accessibilities. Companies should start with that commitment. 

In that same study mentioned earlier, more than two-thirds of respondents said their company hasn’t tested for accessibility within the last three months, and nearly half said their company hasn’t tested within the last six months. 

Accessibility testing is not a one-and-done situation, and requires an ongoing commitment to ensure key digital pathways are providing truly accessible experiences. Too often, designers are isolated and work in a vacuum. 

In that environment, how can they possibly design a high-quality product for a living person about whom they may know next to nothing? 

Inclusive user testing is a key component within inclusive design principles. At the beginning of a project, developers must reject any preconceived notions of who their users are. They need to sit down with the audience they are designing for and learn firsthand about them. Based on user groups, one-on-one conversation and other forms of direct contact, designers can move away from what is “typical” and toward what is personal. From that, they will be able to better ascertain needs, gaps, and solutions. 

Beginning the design process by engaging directly with persons with disabilities is a driver for greater innovation. This type of real-world feedback offers insight early in the process – enabling development of better digital experiences from the start. It also ensures the user experience is intuitive, enjoyable and inclusive for everyone, including people living with disabilities.

Once designers and developers truly grasp the needs of those with disabilities and gain an understanding of what may not work in more traditional design principles, they can better develop products that meet the needs of this audience.  

Building inclusive design principles into a process 

For designers to succeed with inclusive design, here are some important components they should focus on:  

• Regular vertical training.  Bring in specific persons with disabilities to train your designers and engineers. This is key to creating the empathy I’ve discussed. It’s critical to have this in-person or live-online exchange, and base training on the team’s own products.
• Weekly office hours for designers. It’s key that designers can consult with an inclusivity design and accessibility front-end development expert team as they work throughout the week. I have seen this in action over the years and it makes a tremendous difference in efficiency and helps designers avoid unneeded dead ends.
• UX research workshops. These are great for subject matter expert tips and iterative exercises around understanding PwD profiles. 
• Self-service intranet knowledge base. Creating a store of training documents, FAQs and other useful materials builds a knowledge base and becomes the single source of truth for inclusive design. This can help simplify, in time, the complex nature of inclusive design and accessibility. 

The importance of usability and accessibility should not be understated. All websites and apps should provide inclusive experiences for everyone. That begins with shifting accessibility testing left in the development process and gathering real feedback from real people with disabilities.

The post Inclusive user testing – and empathy – are core to inclusive design appeared first on SD Times.

The new testing capabilities are now in beta and will enable teams to identify and resolve accessibility issues before they reach end users.

According to mabl, accessibility is more important than ever, both because of increased digital experiences and updated government regulations. The company said that while software is updated frequently, accessibility checks are often infrequent, even though functional tests are built into the development pipeline. 

“Accessibility is a critical area of quality, as well as an ethical concern that impacts every company – and particularly those with public-facing applications or websites,” said Dan Belcher, co-founder of mabl. “Mabl now empowers quality teams to lead the way in proactively mitigating accessibility issues long before they reach customers, resulting in a better user experience and avoiding costly defects.”

The new accessibility testing capabilities are built on axe-core, which is an accessibility testing engine. The capabilities are fully integrated into mabl’s test automation solution for web, email, PDF, and mobile web testing.

Mabl also noted that combining accessibility testing and actionable reporting will make it easier for development teams to meet the Web Content Accessibility Guidelines (WCAG) versions 2.0 and 2.1.  

The post Mabl incorporates automated accessibility testing appeared first on SD Times.

It was created internally at Microsoft and then released as an open source solution in 2019. 

“We were motivated by Microsoft’s mission to ‘empower every person and every organization on the planet to achieve more.’ We realized that to empower every person, we need to help support all developers in building more accessible products. The power of open-source software is increasing transparency into our methodologies and encouraging trust in our tools. It also allows us to accept contributions and to allow developers to experiment with our tools. These products belong to the community now and I am excited to see how we will develop them together over the coming years,” Mark Reay, principal group software engineering manager for Microsoft, wrote in a post. 

RELATED CONTENT: Global Accessibility Awareness Day highlights need for developer education

The project includes FastPass, which is a five minute process that identifies common accessibility issues and provides recommendations on how to fix them.

The first step of FastPass is an automated scan and the second step is the Tab Stops test, which provides developers with a visualization of how someone would use a keyboard to navigate through the user interface. 

Microsoft has put effort into ensuring that Accessibility Insights doesn’t give false positives and it utilizes scanning libraries that share that commitment, such as axe-core from Deque Systems. 

Accessibility Insights is available in a few different forms. Accessibility Insights for Web can be added as a browser extension for Chrome and Microsoft Edge. Accessibility Insights for Windows is a desktop application that includes axe-windows, which is a scanning library. Microsoft also recently added Accessibility Insights for Android for Android developers. 

The post SD Times Open-Source Project of the Week: Accessibility Insights appeared first on SD Times.

Common accessibility issues that affect sites the most include low contrast text, missing image alt text, empty links, missing form input labels, empty buttons, and missing document language. 

According to GAAD’s website, over 1 billion people worldwide have disabilities, including visual, hearing, motor, and cognitive impairments. 

RELATED CONTENT: 
Getting started on the accessibility track
Why accessible experiments matter
Use feature flags to make your website more accessible

To mark the event’s 10 year anniversary, a new foundation is being created. The GAAD Foundation’s mission is to “disrupt the culture of technology and digital product development to one that includes accessibility as a core requirement.” It will be led by Joe Devon and Jennison Asuncion, the creators of GAAD. 

Preety Kumar, founder and CEO of accessibility company Deque Systems, believes developers don’t overlook accessibility intentionally. The reason, she says, accessibility isn’t always considered is due to a lack of awareness, knowledge, or empathy due to not understanding the challenges people with disabilities have when visiting inaccessible sites.

She believes that developers should be learning about how to make more accessible applications as often as they can, and put that into practice every day. “Just like you have your Olympic swimmer or your golfer or your ballerina, they take that practice and do a little bit every day. What I would wish developers would do is just make it a part of their every day practice over time,” said Kumar. 

There are a number of tools that make it simple for developers to ensure what they’re building is accessible. For example, Deque has the axe DevTools extension, which is a browser extension that offers automated accessibility testing. 

“My goal from day one ever since I started in this field 20 years ago was to automate as much as we possibly could so that it would be easy to do, and we are doing that with machine learning in a very intelligent way,” said Kumar. 

Another extension is the WAVE Web Accessibility Evaluation Tool developed by IAM. It identifies WCAG errors and facilitates human evaluation of applications. 

IBM also earlier this week released updates to its tool for scanning applications for accessibility issues. The IBM Equal Access Accessibility Checker now offers a multi-scan report capability, which makes it easier for developers to discover and fix accessibility issues. 

“On May 20, 2021 the world will celebrate the 10th anniversary of the Global Accessibility Awareness Day (GAAD). According to the GAAD web site, the purpose of GAAD is to get everyone talking, thinking, and learning about digital access and inclusion. Personally, I think 10 years is too long to still be talking about awareness. I would love for the second A in GAAD to stand for ‘Action,’” Si McAleer, program director for IBM Accessibility, wrote in a post. 

GAAD’s website recommends developers get involved by spending an hour today focusing on accessibility awareness. Karen Mardahl provided examples of how to spread awareness on GAAD’s website, which include:

• Caption a video or prepare a transcript
• Write a blog post on digital accessibility awareness
• Create a video demonstrating how you use assistive technology

“Every user deserves a first-rate digital experience on the web. Someone with a disability must be able to experience web-based services, content and other digital products with the same successful outcome as those without disabilities. This awareness and commitment to inclusion is the goal of Global Accessibility Awareness Day (GAAD), a global event that shines a light on digital access and inclusion for people with disabilities,” GAAD’s website states. 

The post Global Accessibility Awareness Day highlights need for developer education appeared first on SD Times.

In addition to the influx of new digital spaces that could have accessibility issues, plaintiff firms have gotten more efficient at building and filing claims. 

Over the course of 2020, there was a slowdown in the number of cases being filed when lockdowns first started happening in March and April. They then started picking back up again over the next months, rising over 50% from March to the end of the year. 

RELATED CONTENT: Accessibility in software development

When it comes to who is targeted most in these lawsuits, retailers have it the worst. 77.55% of accessibility lawsuits were associated with retail businesses. Food service had 7.77% of lawsuits, education had 2.45%, and another 3.38% were grouped into an “other” category. All other industries had two percent of lawsuits or less. “In 2020, thousands of retailers have websites and apps. Those websites are complicated. For retailers, web and app content changes happen often. At the same time, web teams have limited resources,” Jason Taylor, chief innovation strategist at UsableNet, wrote in a blog post explaining the report’s results. 

There were also a number of repeat lawsuits this year, indicating that even when businesses are reported for accessibility issues, they might still not invest in fixing those issues. Over 20% of the lawsuits this year were for companies that already have been sued in the past two years. 

In 2020, 3235 claims were for desktop websites, 296 were for mobile apps, 150 were for video accessibility, 16 were for a combination of web and app, and 3 were for mobile websites. “The type of digital experiences listed in ADA claims are starting to get broader. Video accessibility appeared in digital accessibility lawsuits more often in 2020. It’s easy to argue that missing closed captions or audio descriptions violate the ADA,” Taylor wrote. 

In addition, widgets and overlays that are being used to eliminate or reduce accessibility issues don’t always protect companies. According to the report, over 250 claims were filed against companies using such a solution. 

The post Digital accessibility lawsuits increased by 23% in 2020 appeared first on SD Times.