⭐ If you would like to buy me a coffee, well thank you very much that is mega kind! : https://www.buymeacoffee.com/honeyvig
Hire a web Developer and Designer to upgrade and boost your online presence with cutting edge Technologies

Tuesday, November 22, 2022

How To Search For A Developer Job Abroad

 Working abroad is a popular prospect, yet many people — including professionals in the tech sphere — don’t know where to start. In this article, Andrew Stetsenko gives you an ultimate step-by-step guide to finding and making international opportunities happen.

Many millions of people dream of flying the coop and spending time working abroad.

The opportunity to work abroad is a popular prospect, one undimmed by the years of restriction due to the pandemic and made only more accessible thanks to hybrid working and the rise of the digital native.

However, despite the still-growing desire to work abroad, many people — including professionals in the IT sphere — don’t know where to start. With that in mind, I wanted to write the ultimate guide for finding international employment opportunities.

The article primarily aims at seasoned developers, focusing on where to look for jobs, how to apply, and how to prepare a resume to get called for interviews. I will explore the dos and don’ts during international job interviews and hopefully provide the right sort of advice that should be able to help any IT professional, at any stage of their career, be able to seek out career options abroad.

So, let’s dive in!

Table of Contents:

How To Prepare Your Resume For Getting A Developer Job Abroad #

Let’s start with the basics — your resume.

The critical thing to remember about creating a resume for an international employer is the relevance and flexibility of skills to match your target company’s needs and their specific market.

While there are some hard and fast rules to resume writing that apply no matter where you’re sending an application, your resume needs to be tailored to your new market. This is where a little research goes a long way.

I’ll give you an example: In Malaysia, it’s considered good practice to include your personal details like marital status or date of birth on your resume. However, in other markets, these sorts of details (especially around age, sex, or marital status) are unnecessary or, in some cases, considered inappropriate.

So choose the information you share wisely! Your resume has to reflect your desire to relocate to your chosen market/region, it has to be hyper-personalized in approach, and it needs to sound like you’re passionate about your work.

Resume Length, Format, And Size #

  • Depending on your skill set and experience, the details in a developer resume will vary, but I stand by my rule of not making a resume more than 2 pages.
  • Your resume should be formatted in a simple, easy-to-read font (Lato, Merriweather, or Helvetica, for example).
  • You should also include succinct summaries in sections like About Me or Key Achievements. Keep it short, keep it direct, and don’t repeat information.

Achievements #

  • Instead of giving generic lists of tasks/duties/responsibilities, I advise you to clearly communicate your achievements and accomplishments, with statistics to back them up. This will help you stand out from other applicants.

For example, if you helped develop an app, make sure you include a variety of proven KPI deliverables, such as engagement KPI metrics, UX KPI metrics, and revenue metrics, rather than just a final product showcase:

Developed a social sharing feature using Android Studio, which increased downloads by 150% in the first three months.

Language #

  • Use strong action verbs, such as built, led, deployed, reduced, developed, automated, managed, re-architected, implemented, designed, overhauled, and so on to describe your experience/accomplishments. They will bring a confident tone to your resume.
  • Use industry-specific adjectives like scalable, fault-tolerant, multi-threaded, and robust (to name a few) to highlight your expertise.

Tailoring #

  • Tailoring doesn’t mean changing every line of your resume. It means adapting the direction and desire of your resume for a specific employer and their market.
  • Tailoring your application can take many forms: you can write a personalized cover letter, adapt your introductory paragraph to reflect your desire to work at a specific company, add specific terminology used in the job listing you’re applying for, or angle your achievements to the market and needs of a particular employer. It shows you’ve done your research and are willing and able to adapt your skill set to the needs of an employer abroad.

For some great advice on writing an effective developer resume, head to Stack Overflow and FreeCodeCamp for a further deep-dive.

More after jump! Continue reading below ↓

Where Do You Find An International Developer Job? #

My advice is to build a strategy based around four key international job-seeking means:

  • Job boards and aggregators;
  • Networking and network news;
  • International recruitment agencies;
  • Boolean search logic on Google.

Jumping onto Google and leaving your international career in the hands of algorithmic fate is not the way to approach getting a developer job abroad.

Job Boards And Aggregators #

Job boards and job aggregators (the differences between the two are sometimes vague but transformative to the scale of your international job search) are a popular and effective first port of call for job hunters.

I suggest using job boards for specificity (specific markets and employers in certain countries) and aggregators as overview searches (a generalist overview of where employers are hiring the most and in what sectors).

It’s also important to utilize international job boards that have filters for “relocation” and “visa sponsorship.” In other words, fish in the right pond. Here are some sites I recommend:

  • AngelList Talent is now one of the go-to websites for finding a tech job with a startup.

You need to sign up and complete the mandatory profile information in order to filter for positions that offer visa sponsorship. Once you’re all set up on the site, you can enter your search parameters at https://angel.co/jobs.

Job searching on AngelList
(Large preview)

If you open the Filters tab, you’ll find a section called “Immigration.” Choose “Only show companies that can sponsor a visa” to narrow your search appropriately.

Job search filters on AngelList
(Large preview)

If you don’t turn on this filter, you’ll find all jobs that meet your other criteria, regardless of whether they offer visa sponsorship.

  • Relocate.me is a job board for IT professionals (mainly software engineers) that is designed with relocation in mind.

You can see job opportunities in Europe, Asia, and North America from verified employers who offer relocation benefits. The listings include specific details about the relocation packages, making it easy to compare your options.

Job listings on Relocate.me
(Large preview)
  • Japan Dev is a job board for finding a variety of tech jobs in Japan.

This site features hand-curated jobs from companies that have immediate openings. You can search for positions that offer relocation benefits by clicking the “Jobs with Relocation” button on the home page. You’ll be taken to the Jobs page, where you can further refine your search.

Job searching on Japan Dev
(Large preview)

Most of the listings are for software developers and programmers, but other positions for those who work directly with developers are listed as well.

  • TokyoDev is another site that helps foreign developers find positions in Japan.

You’ll be able to filter your search with labels such as “No Japanese Required,” “Apply From Abroad,” “Residents Only,” and so on.

Job searching on TokyoDev
(Large preview)
  • Landing.Jobs is specifically for tech jobs in Europe, with a focus on Portugal.

When you’re looking for jobs through this site, be sure to find the “Visa & work permit” filter section and select the options you need.

International job search with Landing.Jobs
(Large preview)
  • SwissDevJobs is, as the name indicates, specifically for IT jobs in Switzerland.

The site is well-designed, with a modern and easy-to-navigate UI. In the advanced filters, you can narrow your search down to only show jobs that provide visa sponsorship with a simple checkbox.

Job search filters on SwissDevJobs
(Large preview)
  • Arbeitnow is based in Berlin and features positions in Germany. It makes it simple to filter for jobs that provide visa sponsorship and many other options.
Job searching on Arbeitnow
(Large preview)

Indeed, LinkedIn Jobs, SimplyHired, and Monster are major job aggregators that can be very effective when searching for developer jobs abroad if you use the appropriate keywords.

When searching on LinkedIn, for example, you should add “relocation,” “visa support,” or “visa sponsorship” into the keywords tab, and select the city/country/region that’s your choice for relocation. Of course, some searches can come back with opportunities not quite suited to your situation, but using relevant keywords does a good job of filtering them out.

International job search on LinkedIn
(Large preview)

The same method works for Indeed, Monster, and other similar aggregators. Include “relocation,” “visa sponsorship,” or “visa support” along with your job title (or other keywords) in your search.

Job searching on SimplyHired
(Large preview)

Networking And Network News #

Networking takes time but is a highly effective source of referral recommendations. Utilizing social networks (LinkedIn, GitHub, Twitter, and even Instagram) is a highly personal and effective way of making connections with hiring teams and business leaders worldwide.

But I also urge the eagle-eyed developer to look at the market and network leaders like Hacker News’ Ask HN: Who is hiring? and TechCrunch to see where the movers and shakers are in the tech world and where upticks in hiring are occurring. You can then use these media-led referrals to directly approach companies and hiring managers online, via social media channels, and through their own websites.

International Recruitment Agencies #

For a complete end-to-end application handling service, specialist developer support is available for those looking for a little more hands-on guidance via international recruitment agencies.

My suggested best first ports of call are international talent acquisition agencies like Global Skills Hub, Zero to One Search, Toughbyte, Orange Quarter, and TechBrainJobs, amongst others.

Tech companies often outsource hiring international talent to recruitment agencies, so going through a recruitment agency can be very beneficial. In addition to helping you find the right position, a good recruiter can fill you in on all of the relevant information on a company, including company relocation policy, benefits, and more.

The trick to finding unadvertised yet very alive jobs is by using a rarely-utilized search tool strategy called Boolean logic.

Boolean logic refers to an algebraic formula that creates a clear “true” or “false” value to a data type by using “operator” terms while searching for jobs. For job seekers, “data type” refers to a job vacancy query, and “operator” terms refer to the words used to search for the jobs!

So, applying Boolean logic to a job search very quickly gives you a highly relevant shortlist of live jobs from your chosen country, region, or industry and even from targeted companies’ applicant tracking systems like Lever, Workable, and Greenhouse!

It sounds complex (and the theory behind it is), but the search terms are super effective and simple to deploy. As Reed highlights in their piece on Boolean job searches, “You can use keyword searching almost everywhere, ranging from big search engines through to search functions within smaller sites.”

So, how does it work?

You add the relevant “operator” terms into your search platform or site that refer to specific jobs, skills, or criteria you’re looking for. It’s not as complex as it sounds!

These operator terms are the following:

  • AND: for job searches containing multiple keywords, for example, developer AND javascript AND python will guarantee search results with only those primary keywords as priority indexed terms.
  • OR: for job searches where one of several keywords are prioritized, but not all of them need to be. For example, web developer OR software developer will bring you back jobs with both web and software developer in the title or text, but no other jobs.
  • "" marks: used in searches for a particular phrase or term. For example, putting "mobile developer" into a job search will only bring back mobile rather than other developer roles.
  • *: for searches where you want to start with a certain term. For example, *Engineer will return all jobs that start with the term Engineer, such as Engineering Manager.
  • ( ): when you want to group certain job criteria together. For example, software developer (startup and python) will only bring back specific jobs that fit the startup and tech stack mold you’re looking for.

Example: (site:https://jobs.lever.co OR site: https://apply.workable.com) (engineer OR developer) AND android AND (relocation assistance OR relocation support OR relocation package OR visa sponsorship OR visa support)

Finding a tech job abroad with Boolean logic
(Large preview)

Ex-Amazoner Kip Brookbank has a great article on LinkedIn about using Boolean searches to source a job. Make sure to check it out!

Put It All Together #

The end result of using all four strategies above is a highly targeted, specific, niche, and personal job search that utilizes the best of digital job searching tools and the international recruitment consultant market.

But above all else, the above four points should drive home the feeling that you can get the perfect international tech job with a bit of patience and consideration using these very effective, free tools at your disposal.

By using each specific search platform’s own location tools, you can narrow down the right sort of opportunities for you. Recruiters offer advice, targeted recruitment support, and hands-on help finding a role. Through networking, you can get job referrals. Finally, using Boolean search removes a lot of the stress of sifting through hundreds of jobs.

Your Primary Considerations When Looking For A Developer Job Abroad #

Now you’ve got your resume sorted, and you’re utilizing a raft of different strategies to source your new developer role abroad. So what are your primary considerations beyond clicking the “apply” button?

My advice is to start by building an application strategy (or multiple strategies) that will handle the complexity of relocation and which will keep you focused on building a foundation of credible, flexible professionalism in the eyes of your new employer.

These strategies include some of the points raised above and further details on referral systems, social media approaches, and watching out for red flags!

Application Strategies #

My top 5 applications strategies are:

  1. Apply through specific job boards or aggregators.
    As mentioned above, utilize all digital options at your disposal.
  2. Apply with information from company websites.
    Go directly to your chosen company or use Boolean search terms to shortlist your chosen jobs better.
  3. Seek referrals.
    One of the most versatile and personal job search channels, referrals are found via your network and network news.
  4. Contact your target companies’ HR departments through LinkedIn or email.
    Utilizing social media is no bad thing, and LinkedIn is your primary weapon.
  5. Watch out for red flags.
    Get yourself savvy about what constitutes a poor job advert (Workable provides some eye-opening advice on bad job ads), and use Glassdoor and Blind to sift through companies with bad reviews. You might dodge a career bullet by doing so.

Interview Preparation #

In my experience working with incredibly exacting tech talent, sometimes the basics of interview prep can get lost in the melting pot of assessment testing and high-value candidate handling.

There are some absolutely crucial dos and don’ts for getting a developer job abroad you must adhere to:

Do:

  • Learn about the company.
    Do your research, understand your employer’s journey, and get under the skin of their company’s purpose and mission.
  • Look up interview questions that the company may ask and consider your answers.
    Prepare for any and every question, from coding to critical thinking, from teamwork to timekeeping.
  • Prepare your own questions to ask to show your interest.
    Your research should guide the types of questions you want to ask your prospective new employer. This is your one chance to mine them for information!
  • Be on time. A basic interview must is not be late.
  • Reiterate your desire to relocate and your plans to do so.
    Although I do go into more detail on this below, international employers will want to know how you plan to factor in a relocation into your application. Better to be prepared than caught out.

Don’t:

  • Criticize or otherwise speak poorly about former or current employers.
    It’s not a good look, shows a lack of professionalism, and will reflect poorly on your exit strategies.
  • Imply that your main interest in the job is relocation.
    Although relocation is important, it shouldn’t be the main reason for moving as it makes the job sound like a means to an end.
  • Say “I don’t know” during the interview.
    Contrary to popular belief, you are allowed to make mistakes in an interview. But rather than so you don’t know, say you’d be happy to provide an answer for it in a follow-up interview or post-interview as you don’t have the right information to hand or something to that effect. In short, indicate you may not know now, but you can find out easily.
  • Ask about salary, bonuses, and benefits during the interview.
    Interviews are designed to determine whether you have the character, skills, drive, and determination for a role. The salary and bonus conversation will come later. It’s not a conversation for now unless an interviewer asks you directly. My advice is to be prepared and know your worth!
  • Forget details on your resume.
    You will be asked about certain points on your resume, and your interview will ask you to elaborate on key points. You must know your resume back to front. If you don’t, you run the risk of looking half-prepared and out of your depth.

How To Negotiate A Job Offer And Navigate Discussions About Your Salary #

Contract, salary, and compensation negotiation is a vital moment in your international developer job search. This discussion is not just about money alone; this is your opportunity to talk about everything from relocation packages to IP rights, expat taxes, and more.

  • First things first, do your research.
    Understand the expectations for tech talent in the market (and for the size of the company) you wish to relocate to, and formulate an idea of what you’d want from your pay packet commensurate with the situation of your ideal employer.
  • Be careful about offering salary expectations.
    The best way to approach a discussion around salary is to ask for an offer first rather than put in your expectations based on your research. See if the offer meets your idea of fair pay and relocation package (if offered).
  • Relocation packages
    Does your new employer help with relocation, and if so, by how much and at which stage?
  • Negotiate perks and benefits
    From subsidized travel to commute costs, your employer needs to put a whole package in writing.

Other negotiation considerations should be:

  • Factor in expat taxes: do you pay more tax while working abroad?
  • Discuss intellectual property rights: do you retain any IP in the course of product creation, or are there other options available?
  • Ensure agreement is enforceable: international employment contracts can be a foggy minefield to navigate through, so do your research regarding everything from employer’s rights to e-signing capability.

Relocation, Preparation, And Moving To Your New Developer Job #

Relocation is a complex, emotional, and risky endeavor, and never one a developer should take lightly. I advise relocating developer talent to run through a pre-travel hitlist to guarantee smooth sailing:

  • Learn everything you can about your destination.
    The first thing you should do is deep-dive into the place you’re moving to, from intercity travel to the nuances of the local language. It’ll help reduce the culture shock of the first few weeks and months in a new place.
  • Visit your new location before your move.
    I appreciate international travel isn’t cheap, but if it’s possible to visit pre-move, you’ll benefit from a bit of a headstart with getting around and making some local connections. It’s also beneficial when it comes to meeting potential landlords, work colleagues, and so on.
  • Determine the cost of living in your new location.
    Cost of living fact-finding will be done around the negotiation stage. Still, it’s worthwhile understanding how far your salary will stretch and any nuances around pay and tax bandings, cost of living, rent, food, travel, and the like. That’s where websites like Numbeo come in handy.
  • Understand what’s included in your relocation package.
    This is vital. How much of your travel, accommodation, or relocation will be subsidized, if at all, by a new employer? This is a cornerstone of your financial planning arrangements.
  • Consider your family’s requirements in your planning.
    Finally, although it should never be far from your mind and it no doubt won’t be, your family is an important factor in your relocation. I urge you to include them as much as possible in the process and remember the emotional toll of moving away from home to a new country, as much as the physical and financial.

Finding a developer job abroad is a labor of love — one that has to take stock of everything from financial planning to tweaking and perfecting your resume for an international audience.

It takes a lot of preparation, but the results of a well-planned international job search are incredibly rewarding.

Moving abroad for work is one of the most rewarding and life-changing things you can do, especially if you’re a talented worker with an in-demand skill set like software development.

The world is your oyster!

Using Automated Test Results To Improve Accessibility

 The huge increase in automated accessibility testing adoption is a wonderful first step, but ultimately its impact is limited if we don’t know what to do with the results. In this article, Noah Mashni and Mark Steadman share their approach to how to leverage the automated test results from the accessibility checks to drive change and reach sustainable digital accessibility transformation.

A cursory google search will return a treasure trove of blog posts and articles espousing the value of adding accessibility checks to the testing automation pipeline. These articles are rife with tutorials and code snippets demonstrating just how simple it can be to grab one’s favorite open-source accessibility testing library, jam it into a cypress project, and presto changeo, shifting left, and accessibility has been achieved… right?

Unfortunately, no, because actioning results in a consistent, repeatable process is the actual goal of shift-left, not just injecting more testing. Unlike the aforementioned treasure trove of blog posts about how to add accessibility checks to testing automation, there is a noticeable dearth of content focused on how to leverage the results from those accessibility checks to drive change and improve accessibility.

With that in mind, the following article aims to fill that dearth by walking through a variety of ways to answer the question of “what’s next?” after the testing integration has been completed.

Status Quo

The confluence of maximum scalability and accessibility as requirements has brought most modern-day digital teams to the conclusion that the path to sustainable accessibility improvements requires a shift left with accessibility. Not surprisingly, the general agreement on the merits of shifting left has led to a tidal wave of content focused on how important it is to include accessibility checks in DevOps processes, like frontend testing automation, as a means to address accessibility earlier on in the product life cycle.

Unfortunately, there has yet to be a similar tidal wave of content addressing the important next steps of how to effectively use test results to fix problems and how to create processes and policies to reduce repeat issues and regression. This gap in enablement creates the problem that exists today:

The dramatic increase in the amount of accessibility testing performed in automation is not correlating to a proportional increase in the accessibility of the digital world.

Problem

The problem with the status quo is that without guidance on what to do with the results, increased testing does not correlate with increased accessibility (or a decrease in accessibility bugs).

Solutions

In order to properly tackle this problem, development teams need to be enabled and empowered to make the most of the output from automated accessibility testing. Only then can they effectively use the results to translate the increase in accessibility testing in their development lifecycle to a proportional decrease in accessibility issues that exist in the application.

How can we achieve this? With a combination of strategically positioned and mindfully structured quality gates within the CI/CD pipeline and leveraging freely available tools and technologies to efficiently remediate bugs when they are uncovered, your development team can be well on their way to effectively using automated accessibility results. Let’s dive into each of these ideas!

Quality Gates

Making a quality gate is an easy and effective way to automate an action on your project when committing your code. Most development teams now create gates to check if there are no linting errors, if all test cases have passed, or if the project has no errors. Automated accessibility results can fit right into this same model with ease!

Where Do The Gates Exist?

For the most part, the two primary locations for quality gates within the software development lifecycle (SDLC) are during pull requests (PRs) and build jobs (in CI).

With pull requests, one of the most commonly used tools is GitHub Actions, which allows development teams to automate a set of tasks that should be completed or checked when code is committed or deployed. In CI Jobs, the tools’ built-in functionality (Azure, Jenkins) is used to create a script that checks to see if test cases or scenario has passed. So, where does it make sense to have one for your team?

It all depends on what level development teams want to put a gate in place for accessibility testing results. If the team is doing more linting and component-level testing, the accessibility gate would make the most sense at a pull request level. If the automated test is at an integration level, meaning a full baked-out site ready for deployment, then the gate can be placed with a CI job.

Types Of Gates

There are two different ways that quality gates can operate: a soft check and a hard assertion.

A soft check is relatively simple in the definition. It looks at whether or not the accessibility tests were executed. That is it! If the accessibility checks were run, then the test passes. In contrast, assertions are more specific and stringent on what is allowed to pass. For example, if my accessibility test case runs, and it finds even ONE issue, the assertion fails, and the gate will say it has not passed.

So which one is most effective for your team? If you are looking to get more teams to buy into accessibility testing as a whole, a best practice is to not throw a hard assertion right away. Teams initially struggle with added tasks or requirements, and accessibility is no different. Starting with a soft gate allows teams to see what the requirement is going to be and what they are required to be doing.

Once a certain amount of time has passed, then that soft gate can switch to a hard assertion that will not allow a single automated issue out the door. However, if your team is mature enough and has been using accessibility automation for a while, a hard assertion may be used initially, as they already have experience with it.

Creating Effective Gates

Whether you are using a soft or hard gate, you have to create requirements that govern what the quality gate does with regard to accessibility automated results. Simply stating, “The accessibility test case failed,” is not the most effective way to make use of the automated results. Creation of gates that are data-driven, meaning they are based on a piece of data from the results, can help make a more effective gate that matches your development team or organization’s accessibility goals.

Here are three of the methods of applying assertions to govern accessibility quality:

  • Issue severity
    Pass or fail based on the existence or count of specific severity issues (Critical, Serious, and so on).
  • Most common issues
    Pass or fail based on the existence or count of specific issue types which are known to be most common (either global or organization specific).
  • Critical or Targeted UI /UX
    Do these bugs exist in high-traffic areas of the application, or do these bugs directly impede a user along a critical path through the UX?

Fixing Bugs

The creation and implementation of quality gates is an essential first step, but unfortunately, this is only half the battle. Ultimately a development organization needs to be able to fix the bugs found at the various quality gate inspection points. Otherwise, the applications’ quality will never improve, and nothing will clear the gates that were just put in place. What a terrifying thought that is.

In order to translate the adoption of the quality gates into improved accessibility, it is vital to be able to make effective use of the accessibility test results and leverage tools and technologies whenever possible to help drive remediation, which eliminates accessibility blockers and ultimately creates more inclusive experiences for users.

Accessibility Test Results

There is a common adage that “there is no such thing as bug-free software,” and given that accessibility conformance issues are bugs, this axiom applies to accessibility as well. As such, it is absolutely necessary to be able to clearly prioritize and triage accessibility test results in order to apply limited resources to seemingly unlimited bugs to fix them in as efficient and effective a way as possible.

It is helpful to have a few prioritization metrics to assist in the filtration and triage work when working with test results. Typically, context is an effective top-level filter, which is to say, attacking bugs and blockers that exist in high-traffic pages or screens or critical user flows is a useful way to drive maximal impact on the user experience and the application at large.

Another common filter, and one that is often secondary to the “context” filter mentioned above, is to prioritize bugs by their severity, which is to say, the impact on the user caused by the bug’s existence. Most free or open-source automated accessibility tools and libraries apply some form of issue severity or criticality label to their test results to help with this kind of prioritization.

Lastly, as a tertiary filter, some development teams are able to organize these bugs or tasks by thinking about the level of effort to implement a fix. This last filter isn’t something that will commonly be found in the test results themselves. Still, developers or product managers may be able to infer a level of effort estimation based on their own internal understanding of the application infrastructure and underlying source code.

Thankfully, accessibility test results, for the most part, share a level of consistency, regardless of which library is being used to generate the test results, in that they generally provide details about what specific checks failed, where the failures occurred in terms of page URL and sometimes even CSS or XPath as well as specific component HTML, and finally actionable recommendations on how to fix the components that failed the specific checks. That way, a developer always has a result that clearly states what’s wrong, where’s it wrong, and how to fix what’s wrong.

In the above ways, developers can clearly stack, rank, and prioritize tasks that result from automated accessibility test results. The test results themselves are typically designed to be clear and actionable so that each task can be remediated in a timely fashion. Again, the focus here is to be able to effectively deliver maximal impact with limited resources.

Helpful Tools #

The above strategies are well and good in terms of having a clear direction for attacking known bugs within a project. Still, it can be daunting to figure out whether one’s remediation solution actually worked or further to figure out a path forward to prevent similar issues from recurring. This is where a number of free tools that exist in the community can come into play and support and empower development organizations to expedite remediation and enable validation of fixes, which ultimately improves downstream accessibility while maintaining development velocity.

One such family of free tools is the accessibility browser extension. These are free tools that can help teams locate, fix, and validate the remediation of accessibility bugs. It is likely that whatever accessibility library is being used in the CI/CD pipeline has an accompanying (and free) browser extension that can be used in local development environments. A couple of examples of browser extensions include:

The browser extensions allow a developer to quickly and easily scan a page in the browser, identify issues on the page, or as in the case described above, they can validate that an issue that was detected during the testing automation process, which they have since remediated, no longer exists (validation!). Browser extensions are also a fantastic tool that can be leveraged during active development to find and fix bugs before code gets committed. Often, they are used as a quality check during a pull request approval process, which can help prevent bugs from making their way downstream.

Another group of free tools that can help developers fix accessibility bugs is linters which can be integrated within the developers integrated development environment (IDE)and automatically identifies and sometimes automatically remediates accessibility bugs detected within the actual source code before it compiles and renders into HTML in a browser.

Linters are fantastic because they function similarly to a spell checker in a document editor tool like Microsoft Word. It’s largely fully automated and requires little to no effort for the developer. The downside is that linters typically have a limited number of reliable checks that can be executed for accessibility at the point of source code editing. Here are some of the top accessibility linters:

Equipping a development team with browser extensions and linters is a free and fast way to empower them to find and fix accessibility bugs immediately. The tools are simple to use, and no special accessibility training is required to execute the tests or consume and action the results. If the goal is to get farther faster with regard to actioning automated accessibility test results and improving accessibility, the adoption of these tools is a great first step.

The Next Level

Now that we have strategies for how to use results to improve accessibility at an operational level, what’s next? How can we ensure that all of our organization knows that accessibility is a practical piece of our development lifecycle? How can we build out our regression testing to include accessibility so that issues may not be reintroduced?

Codify it!

One way we can truly ensure that what we have created above will be done on a daily basis is to bring accessibility into your organization’s policy (also known as code policy or policy of code) — establishing such means that accessibility will be included throughout the SDLC as a foundational requirement and not an optional feature.

Although putting accessibility into the policy can take a while to achieve, the benefits of it are immeasurable. It creates a set of accessible coding practices that are clearly defined and established for how accessibility becomes part of the acceptance criteria or definition of “done” at the company level. We can use the automated accessibility results to drive this policy of code and ensure that the teams are doing full testing, using gates, and fixing the issues set by the policy!

Automate it!

Most automated accessibility testing libraries are standard out-of-the-box libraries that test generically for accessibility issues that exist on the page. The typical amount of issues caught is around 40%, which is a good amount. However, there is a way in which we can write automated accessibility tests to go above and beyond even more!

Accessibility regression scripts allow you to check accessibility functionality and markup to ensure that the contents of your page are behaving the way they should. Will this guarantee it works with a screen reader? Nope. But it will ensure that the accessible functionality of it is properly working.

For example, let’s say you have an expand/collapse section that shows extra details have you click the button. Automated accessibility libraries would be able to check to ensure the button has accessible text and maybe that it has a focus indicator. Writing a regression script, you could check to ensure the following:

  • It works with a keyboard (Enter and Space);
  • aria-expanded=” true/false” is properly set on the button;
  • The content in the expanded section is properly hidden from screen readers.

Doing this on key components can help ensure that the markup is properly set for assistive technology, and if there is an issue, it can be easier to debug if the issue is in code or potentially a bug in the assistive technology.

Conclusion #

The “shift left” movement within the accessibility industry over the last few years has done a lot of good in terms of generating awareness and momentum. It has helped engage and activate companies and teams to actually take action to impact accessibility and inclusion within their digital properties, which in and of itself is a victory.

Even so, the actual impact on the overall accessibility of the digital world will continue to be somewhat limited until teams are not only empowered to execute tests in efficient ways but also that they are enabled to effectively use the test results to govern the overall quality, drive rapid remediation, and ultimately put process and structure in place to prevent regression.

In the end, the goal is really more than simply shifting left with accessibility, which often ends up taking what a bottleneck of testing in the QA stage of the SDLC is and simply dragging it left and upstream and placing it into the CI/CD pipeline. What really is desired, if sustainable digital accessibility transformation is the goal, is to decentralize the accessibility work and democratize it across the entire development team so that everyone participates (and hopefully into the design as well!) in the process.

The huge increase in automated accessibility testing adoption is a wonderful first step, but ultimately its impact is limited if we don’t know what to do with the results. If teams better understand how they can use these test results, then the increase in testing will, by default, increase accessibility in the end product. Simple gatekeeping, effective tool use and a mindful approach can have a major impact and lead to a more accessible digital world for all.