Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Mar 04 2020
Mar 04

The process of auditing a website for ADA accessibility compliance, as described by the W3C(R) Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0  falls into two essential categories: automated and manual. The automated part of the process is relatively straightforward. It’s simply a matter of leveraging the right tools for diagnosing non compliance with WCAG 2.1. The next and indispensable step tends to be open-ended and undefined. 

The WCAG-EM is the definitive to the evaluation process.

[WCAG-EM documentation]... is intended for people who are experienced in evaluating accessibility using WCAG 2.0 and its supporting resources. It provides guidance on good practice in defining the evaluation scope, exploring the target website, selecting representative samples from websites where it is not feasible to evaluate all content, auditing the selected samples, and reporting the evaluation findings. It is primarily designed for evaluating existing websites, for example, to learn about them and to monitor their level of accessibility. It can also be useful during earlier design and development stages of websites. 

The process is very well defined and W3C(r) provides a sample reporting tool for audits. 
 
We, at Promet Source like to tinker and apply small changes, without deviating from the process to improve the report and make it easier to use and read. Our version of the Website Accessibility Evaluation Report Generator is Google Doc based, provides an executive summary, a simple dashboard of results and is FREE! This template from Promet reflects WCAG 2.1 guidelines, and designed  for use by accessibility analysts and developers to detect errors missed by automated testing.

As a part of our commitment to advancing inclusivity and web experiences that are accessible to a full range of differently abled web users, we are making this tool available to all.
 

Small preview of the tool

 

Why Manual Accessibility Testing Matters

Manual accessibility testing goes deeper and wider than automated scans. It includes:

  • Keyboard testing
  • Color contrast testing
  • Screen reader testing
  • Link testing
  • Tables and forms testing
  • Cognitive testing
  • Mobile testing

The types of non-compliance issues, which are detected by manual testing tend to have the greatest likelihood of exposing site owners to ADA accessibility lawsuits.
 
Keep in mind that diagnosing a website for accessibility and fixing any noncompliance issues that are uncovered is not a one-size-fits-all endeavor. 

Every site has a distinct set of strengths and challenges, and in the current environment, the stakes are high for getting it right. That’s why we at Promet Source believe that tapping the expertise of a Certified Professional in Accessibility Core Competencies (CPACC) is the most efficient and effective path for bringing a site into compliance. We follow a distinct WCAG 2.1 auditing and remediation process that consists of a series of value-added steps in a specific order.  

Circle process graphic depicting web accessibility testing

 

Value-Added Elements

There is a high degree of added value that occurs during and following an accessibility audit. The education, consultation, and opportunity to dig deep and deconstruct aspects of a site that no longer serve the organizational mission fuels a better and wiser team of developers and content editors. For a number of reasons, web accessibility also enhances SEO.
 
In the current climate, websites are highly dynamic and serve as the primary point of engagement for customers and constituents. Constantly evolving sites call for an ongoing focus on accessibility, and an acknowledgement that staff turnover can erode the education, expertise, and commitment to accessibility that is in place at the conclusion of an audit. 
 
For this reason, a bi-annual or annual audit is a highly recommended best practice. 

Interested in kicking off a conversation about auditing your site for accessibility? Contact us today.
 

Feb 23 2017
Feb 23

Why should I load test my site before launch?

Website load testing is used to simulate user interaction with a website, increase the frequency or the number of interactions, collect the results of system usage, and then analyze them to aid in system improvement towards desired results.

There are three key phases of performing load testing.

- Analysis & Acceptance: Obtain a prediction of potential load and agree on Acceptance Criteria

- Behaviour: Plan and design the test cases and test steps that represent typical usage and prepare the target environment

- Execute, Modify & Repeat: Execute the test and measure the results. If necessary, implement improvements and repeat.

Website Load Testing Phase 1: Analysis and Acceptance


Typically during site migrations we analyze previous site’s traffic by looking at google analytics. We look for traffic patterns and interaction patterns. Looking for highest pageview days over a period of a year or more gives us an idea of typical peak load. Sometimes the trends are seasonal, as in eCommerce sites, so it’s important to look at a longer period of time. User interaction patterns give us an idea on how the end user interacts with the site: how they are logging in, which pages are most popular, how many pageviews are typically generated by the user, what actions they perform. From this data we will create target load numbers and use cases. Then, we can agree on the acceptance criteria of site performance. Those criteria may include total number of error free requests per minute, Apex scores or average response times.

load testing site traffic overviewload testing site traffic overview image 2

Website Load Testing Phase 2: Behaviour

Build test cases and test steps that will be run by the load test. Sites that provide information typically have scripts that simulate several users consuming information on some of its popular pages. Applications will have scripts which run the user through achieving a goal, such as signing up for an email, creating an account, searching for specific content, etc.

Website Load Testing Phase 3: Execute, Modify & Repeat  


At Promet Source, we prefer to use Load Storm for test execution along with New Relic on the server. Load Storm spins up cloud servers which simulate user behaviour through browser requests. It collects the data on each request and provides a graphical representation of the results. By using New Relic, we are able to see performance patterns. We look for average response times, peak response times, slow responding requests, and error rates in order to find a point of failure. New Relic gives us the ability to fine tune the site by providing insights into database performance, which modules or transactions take the most time to complete and shows us which parts of the application have the heaviest usage. This data gives our development team visibility into where the site limitations are and where to focus our efforts.

Load Storm User Testing Graph image

At the conclusion of load testing the application performs better and everyone (most importantly, the client) has peace of mind that once the site goes live it will be a pleasant user experience for both the end user and the technical staff or internal development team supporting the site.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web