SDK Primer Part 1: Basic SDK concepts

Before you begin working with Level Access Testing SDKs, take time to learn the key concepts and terminology. This foundational knowledge will help you understand how SDKs function and how to use them effectively to support your digital accessibility efforts.

Note:  Level Access provides Software Development Kits (SDKs) for various programming languages. We also provide sample projects to illustrate how to use our SDKs with popular testing frameworks. 

• Example programming languages:  Java, JavaScript, C#, Python, Ruby
• Example testing frameworks: Cucumber, Jest, Mocha, Cypress, WebdriverIO
• Example package manager: NPM

This SDK primer consists of three parts. After you learn more about basic SDK concepts and terms, proceed to examples. They'll illustrate how to use JavaScript programming language, the Cucumber testing framework, and the npm package manager. 

On this page: 

• What is a programming language?
• What is a package manager?
• What is a web automation testing framework? 
  • Purpose of a testing framework
  • Benefits of a testing framework
  • Components of an example testing framework
  • Combination of a programming language and a testing framework
• What are SDKs?
  • Purpose of SDKs
  • What SDKs cannot do?
  • Where SDKs reside (private repository)
  • How to use SDKs?
    • Run tests to get results
    • View and use testing results
    • Use Quality Gates to handle code deployment
    • Track issues in the Level Access Platform
    • How SDKs use Access Engine for accessibility testing?

What is a programming language?

Spoken languages like English, Arabic, or Japanese follow specific rules called syntax, which dictate how words form correct sentences—for example, “He likes cookies,” not “Likes he cookies.” Similarly, programming languages use syntax to structure instructions for computers. If the syntax is incorrect, the program won’t run properly. That is, each programming language has rules that must be followed for a program to run. 

A combination of logically arranged programming statements creates a function. Together, multiple functions  can build complex features.

Some popular programming languages are JavaScript, Python, Ruby, C++, and Java. We discuss the use of JavaScript. For details, refer to SDK Primer Part 2.

What is a package manager?

A package manager is a collection of software tools that automates installation, upgrades, configuration, and removal of software packages like our SDKs.

What is a web automation testing framework?

This section describes the purpose of a web automation testing framework, the benefits you get from using a testing framework, and the components of a testing framework. Also, we provide an example combination of a programming language, testing framework, and a package manager.   

Purpose of a testing framework

We'll refer to a web automation testing framework as a "testing framework". It is a tool designed to automate the navigation, interaction, and testing of web applications. 

Developers use it to write and run tests in a specific programming language. These tests simulate how users interact with a website to check if everything works as expected. For example, if your web application is an e-commerce site with search capabilities, a typical test might involve searching for a product and verifying that the results are displayed correctly. This ensures that the search functionality behaves as expected.

This SDK Primer introduces Cucumber, a popular testing framework, which enables users to accomplish just that. Refer to SDK Primer Part 3: Testing framework guidance (Cucumber example).

Benefits of a testing framework

The following table lists specific benefits of testing frameworks:

Components of an example testing framework  

The following table lists components of a testing framework. 

Combination of a programming language and a testing framework

Testing frameworks interface with a browser, which is used to navigate to website pages, click links, type in forms, and so on.

Here is an example combination of a programming language, testing framework, and package manager. 

• Language: JavaScript
• Test framework: Selenium
• Package Manager for installation: NPM

The following graphic illustrates the interaction process:

• We use the same process, regardless of whether you use Selenium, or any other testing framework.  In our examples, we'll show the use of selenium-webdriver, which automatically aligns the versions of the web browser and web driver, a constraint imposed by Google Chrome which requires its web driver to be in sync with its own version. Refer to:
  • SDK Primer Part 2: Programming language guidance (JavaScript Coding Example)
  • SDK Primer Part 3: Testing framework guidance (Cucumber example).
• All file directories use the *nix formatting: (/this/is/a/directory).
• All commands and references to the file system made in code are Linux references. For Windows,  other than the directory file structure, they would be mostly identical.

What are SDKs?

This section describes Software Development Kits (SDKs), what they are, what they are not, and where they reside.

Purpose of SDKs 

• SDKs are collections of pre-built functions and tools—often referred to as code libraries—that help developers complete repetitive tasks more efficiently. For example, the Level Access Testing SDKs allow you to create accessibility scans, apply best practices, run tests, and automatically save results to the Level Access Platform.
• SDKs offer interfaces and shortcuts to underlying code, enabling developers to tailor solutions to their specific environments. A single line of code added to an existing interface—such as a step in an automated test framework—can trigger the SDK to run tests and save results without additional effort.
• By using SDKs, developers can address specific business needs with minimal custom coding. For example, the Level Access Testing SDKs include pre-built shortcuts for scanning and sending results to the Level Access Platform.

Note: To install, upgrade, configure, and remove the Level Access Testing SDKs, you must use a relevant package manager. 

What SDKs cannot do?

• SDKs do not enable browser interaction. For example, they do not automatically open a web browser, navigate to a website, type text on an input form, and click a button. Instead, these tasks are typically performed by the testing framework.
• SDKs are not the test engine itself.
• SDKs are not a specific programming language. Rather, SDKs are written in a variety of programming languages. Each SDK, written in a particular language, must use tests written in the same language. The testing framework binds the SDKs and tests together. 

Where SDKs reside (private repository)

The Level Access Testing SDKs are held in a private repository. You must authenticate before you can download and install the SDK libraries for each programming language. 

To configure this repository, read Get started with Access Continuum. 

How to use SDKs? 

Use SDKs to run tests, get, view and assess the results, and handle code deployments based on a set of rules prompted by the results. 

SDKs are most effective when an organization has an existing Continuous Integration/ Continuous Delivery (CI/CD)  pipeline, which is already deploying an end-to-end test automation framework. For example, companies that practice Behavior-Driven-Development (BDD), can benefit greatly from SDKs, by injecting a single line of code per “test”. 

Run tests to get results

Here is an example test that your automated testing framework can run:  

1. Open a web browser.
2. Navigate to www.google.com.
3. Type cats into the search bar.
4. Select Search.

This test is looking at two things, the ability to open the google.com site and to search for “cats”. 

You can add accessibility testing into this existing test, by injecting a line of code, as follows:

1. Open a web browser.
2. Navigate to www.google.com
3. Test for Accessibility.
4. Type “cats” into the search bar.
5. Select Search.
6. Test for Accessibility.

In this example, we are testing for accessibility twice, at the www.google.com homepage, and on the search results page.

View and use testing results

Testing results, also called findings, are available in the Level Access Platform either at the organization level, or directly in a terminal.

• View the results sent to the Level Access Platform, in the same way that you can view the results of an automated scan initiated within the Level Access Platform UI.
• Analyze the results to drive decisions. Depending on the accessibility goals of your organization, use the results to perform the necessary operation:
  • Monitor the state of accessibility in your environment
  • Stop deployments
  • Start remediation by creating projects and tasks. 

Use Quality Gates to handle code deployment

If you are using a CI/CD pipeline, which is set up to promote and deploy code from one environment to another (Develop → QA→ Production), you can create a set of rules around the SDK findings to control those deployments. 

The rules can identify issues introduced by recently merged code. At this stage, you can investigate the root cause—for instance, you might find that an accessibility guideline was overlooked, resulting in failure to meet the minimum accessibility standards.

Track issues in the Level Access Platform 

If the scan results are uploaded to the platform, you can:  

• Create projects and tasks for identified issues (findings).
• Group tasks within projects, in the relevant workspace of the platform.
• Link those issues to a ticket in issue tracking software, such as Jira, Asana, or Azure DevOps, where remediation work can be assigned and completion tracked. 

How SDKs use Access Engine for accessibility testing?

Level Access Testing SDKs allow you to integrate accessibility testing in your continuous integration (CI) pipeline using Access Engine—the tool that discovers accessibility issues on a particular page. This allows your development team to find and resolve accessibility issues early on and in a more cost-effective way, before they’re released into the production environment.

Specifically, Level Access Testing SDKs inject Access Engine into a rendered Document Object Module (DOM) to find accessibility issues. The HTML DOM is a hierarchical data representation of a web page which programming languages, such as JavaScript, can access and manipulate. 

Note: 

• Access Engine is bundled in all versions of the SDK libraries.
• Access Continuum integrates the Access Engine with test automation frameworks, so that you can run accessibility tests on code snippets, nodes of a page, or a fully rendered page, while your organization is running their other automated tests. For more details, go to: Access Continuum overview.

Now that you've learned key concepts and terms, proceed to SDK Primer Part 2: Programming language guidance (JavaScript Coding Example).