When I brought it up in our group chat, I realized I wasn’t the only one. Others were stuck too. Some couldn’t verify their phone numbers, others had their cards rejected, and a few didn’t even know what kind of card would work.

That’s what inspired this guide.

This article walks you through the exact steps to create an AWS account, with practical tips for troubleshooting common problems (especially for users in Nigeria), based on solutions that worked for me and others.

Table of Contents

• What is AWS?

• Steps to Create an Account

• Common Setup Issues and How to Solve Them

• Conclusion

What is AWS?

Let’s say you want a place to live. Normally, you’d have to buy land, build the house from the ground up, handle the wiring and plumbing, and maybe even oversee construction. After all that, you’d still need to furnish the house – buy furniture, paint the walls, maybe call in an interior decorator. Then you'd have to reach out to the electricity company to connect your house to the grid…and so on.

Compare that to renting a house. With renting, a lot of that heavy lifting is already done. You move into an already-built space. If you want to repaint or get different furniture, you can. If electricity isn’t already included, you call someone to help. But still, you’re dealing with multiple providers: the landlord, the interior decorator, the electrician, and so on.

Now imagine there’s a single provider that gives you access to everything in one place: a ready-to-use space, electricity, furniture, interior design, and even maintenance, all on-demand – like a pre-furnished apartment. All you have to do is log in to your account, select the services you need, and pay only for what you use. If you're away for a while (say, on a long vacation), you can pause your utilities while you’re gone. That’s basically what AWS does, but for computing power and digital infrastructure.

Amazon Web Services (AWS) is a platform that gives you access to computing tools like servers (EC2), storage (S3), databases, and more, without needing to “build the house” yourself. You only pay for what you use. Most people (especially students or learners) start with the free tier, which gives you enough resources to learn and build basic projects without being charged. And that’s what you’ll learn how to set up here.

Steps to Create an Account

There are 5 steps involved in successfully creating an AWS free tier account. We’ll go through them one by one.

Step 1: Set up and verify your email address

Go to aws.amazon.com and click on “Create Account” at the top right of the screen.

You should be taken to the sign-up page. But you might be redirected to the sign in page instead. If that happens, scroll down a bit until you see the “New to AWS? Sign Up” button. Click it to go to the sign-up page.

On the sign-up page, you’ll be asked to:

• enter a root user email address

• choose a name for your AWS account (you can change this name in your account settings after you sign up)

Tip: Use an email you check regularly. AWS sends important verification and billing alerts that you don’t want to miss.

Then click on “Verify email address”. A text-based CAPTCHA will pop up to verify your identity. In the field provided, type in the characters shown and submit.

Tip: The refresh icon lets you load a new image if the current one is hard to read. You can also click the speaker icon to get an audio CAPTCHA if you have visual impairments.

You’ll receive a 6-digit verification code in your email. Enter the code in the email confirmation pop-up then click “Verify” to verify your email address.

Tip: If you don’t find the code in your inbox, check your spam folder for an email from Amazon Web Services. If it’s not there, wait for up to 5 minutes, then check again. If you still don’t get it, click the “Resend Code” button to have the code re-sent to your email.

Once your email is verified, you’ll get a success notification and on the same page be asked to enter your password. Your password must be at least 8 characters long and must contain at least 3 of the following:

• numbers

• upper-case letters

• lower-case letters

• non-alphanumeric characters (such as !, @, #, and so on)

Enter the password again in the “Confirm root user password” field and click “Continue”.

Step 2: Enter your contact information

You’ll be asked to choose between a Personal or Business account. If you're signing up for learning or personal projects, the Personal option is fine.

Then, you’ll need to fill in your contact information. This includes:

• Your full name

• Your phone number (with country code)

• Your address

• Your postal code

Then check the box that says “I have read and agree to the terms of the AWS Customer Agreement.”

Step 3: Add your billing information

The next step is to enter your billing information. Here you’ll be required to enter:

• Your billing country

• Your credit or debit card details

• Your billing address (could be your contact address or a different address)

Click “Verify and continue” to move on to the next step.

Note: AWS may temporarily hold up to $1 (or an equivalent amount in local currency) as a pending transaction for 3-5 days to verify your identity.

Step 4: Verify your identity

Once you’ve filled in your billing information, AWS will ask you to verify your identity by entering a code they’ll send to you. You can choose to receive the code via text message (SMS) or voice call.

Enter your country code and mobile phone number and click “Send SMS” (if you chose the text message option) to continue.

You’ll be required to complete another CAPTCHA. Enter the characters in the image shown to confirm your identity.

Enter the code you received in the field and click “Verify and continue.”

You might see an error message that says, “There was a problem with your payment information.” This means AWS couldn’t verify your payment method. When this happens, it's usually due to one of the following reasons:

• The card you used isn’t one that AWS accepts

• You entered incorrect card details

• The name and billing address you provided don’t match what your card issuer has

• Your card doesn’t have at least $1 available for the temporary hold

If you get this error, AWS will ask you to sign in and update your payment method. Here’s how to do it:

1. Sign in to your AWS account. You may automatically be taken to the Billing and Cost Management dashboard. If not, use the search bar at the top of the page to search for "Billing", then click on the Billing and Cost Management service.

2. In the left-hand menu, scroll down and click "Payment preferences."

3. Click "Edit" next to your existing card details to correct the billing name and address, or click "Add payment method" to enter a new payment method.

   

Step 5: Choose a support plan

Next, AWS asks you to pick a support plan. Select the Basic support (Free) plan. It’s the recommended plan for new users who are just getting started with AWS.

You’ll still get access to the AWS Free Tier, which includes:

• 750 hours of EC2 compute

• 5GB of S3 storage

• and many more services you can experiment with for free (for up to 12 months)

Note: You can upgrade your plan later if needed. No need to pay now.

Step 6: Sign In and Explore the Console

Once everything is verified, you’ll be able to sign in to the AWS Management Console. This is your dashboard for managing all AWS services, from setting up virtual servers (EC2) to experimenting with storage (S3) or databases (RDS).

Note: Sometimes, it takes a few hours for your account to become fully active. If it takes more than 24 hours, reach out to AWS Support via chat or email.

Common Setup Issues and How to Solve Them

I’ve summarized the most common issues I’ve come across or heard about with quick fixes here:

Conclusion

Getting your AWS account set up is an important step in your cloud journey. Once you’re in, you’ll be able to explore powerful tools, build projects, and gain hands-on experience all within the free tier.

If you're reading this because you're just starting out like I was, well done. You’ve already taken one of the most important steps. Keep learning, keep building, and don’t be afraid to ask for help when you need it.

I had the same questions when I started learning about cloud-native technologies. In this article, I'll share my understanding of core observability concepts, introduce essential observability tools, and share insights from a related project I’m working on.

Table of Contents

• My Introduction to Cloud Native Technologies

• What is Observability?

• Types of Observability Data

  • 1. Metrics

  • 2. Logs

  • 3. Traces

• Observability Tools

  • Prometheus

  • OpenTelemetry

• What are OTLP Resource Attributes?

• Importance of OTLP Resource Attributes

• How My Project Work Fits into All This

• Conclusion

• Additional Resources

My Introduction to Cloud Native Technologies

I recently got selected as a mentee for the Linux Foundation Mentorship to work on the CNCF - Prometheus project. The project is UX-focused, and for the next few months, I'll be working with my mentors to understand how users expect to use OpenTelemetry Line Protocol (OTLP) Resource Attributes in Prometheus.

That's quite a mouthful, I know. I was overwhelmed at first, and honestly, I’m still figuring it out. This is my third week, and although I still have a lot to learn—given that I had no knowledge of cloud native technologies when I applied for this internship—I've already learned quite a bit.

As I often do, I intend to document what I learn through articles to help reinforce concepts in my memory and serve as a resource for other newcomers who may find themselves grappling with these technical terms in the future. You know what they say: you can't say you've understood something until you're able to explain it to someone else who's also new to the topic.

What is Observability?

First, I had to learn what the unfamiliar terms meant—and there were a lot of them flying around. OpenTelemetry. Prometheus. Resource attributes. I’ve come to understand that these terms fall under one umbrella: Observability. Let's start there.

Let’s use a food delivery app to illustrate. When someone orders food, a lot happens behind the scenes:

• The app connects to different services (restaurants, payments, delivery)

• Data flows between different systems to process the order, assign a driver, and track delivery

Engineers need to monitor all the processes to ensure everything works smoothly. Are orders taking too long to process? Is the payment system failing? Does the app suddenly crash under load? Which part of the system is causing delays?

To answer these questions, engineers instrument their code. This means that they configure it to send back real-time data about the state, performance, and behavior of the application. This practice of understanding what's happening inside a complex system based on the data it generates is known as Observability.

You can see the process illustrated in the image below:

In the above flowchart diagram, you can see how data might move through a food delivery application system. The flow starts with a User who orders food from a Food App. The Food App connects to three services (Restaurant, Payment, and Delivery). All these components send data to OpenTelemetry, which collects three types of data: Metrics, Logs, and Traces. OpenTelemetry then forwards only the Metrics data to Prometheus, which stores metrics.

Types of Observability Data

There are three key types of data that systems generate for observability:

1. Metrics

Metrics are numerical measurements collected over time that represent the state or performance of your system. Examples in a food delivery app would be the number of orders processed per minute, average order processing time in milliseconds, number of active users or delivery drivers, and so on.

2. Logs

Logs are text-based records of discrete events that occur within your application. Logs for our food delivery app would look something like this:

ERROR: Payment failed for order #12345 - Credit card declined
INFO: Driver #789 assigned to order #12345

3. Traces

Traces track the entire lifecycle of a request as it moves through different services in a system. They help engineers see how different components interact and identify bottlenecks in complex, distributed systems.

For example, in our food delivery app, a single order request might go through the following steps:
User places an order → Request sent to restaurant system → Payment processor verifies payment → Delivery system assigns a driver → User receives confirmation.

Each step in this journey is recorded as part of a trace. This helps engineers pinpoint where delays occur and optimize the system for better performance.

Observability relies on metrics, logs, and traces working together to provide full system visibility. Metrics tell you something is wrong (“Error rate increased by 5%”). Logs tell you why it happened (“Payment failed due to invalid card details”). Traces show exactly where it happened (“Delay in restaurant service response”).

Observability Tools

Observability tools give you visibility into what’s going on within your application. There are a lot of them, but for the purpose of this article, we’ll talk about two: Prometheus and OpenTelemetry.

Prometheus

Prometheus is an open-source monitoring and alerting toolkit. It does two things:

• Collects data from applications, specifically metrics (remember the data types we talked about earlier)

• and stores them in a time-series database.

A time-series database is a database specifically designed to handle measurements or events that occur over time.

Prometheus uses what's called a pull-based model to collect metrics from applications. Pull-based means Prometheus actively requests (pulls) data from services at regular intervals. Think of it like refreshing a webpage to get the latest content.

OpenTelemetry

OpenTelemetry (OTel) collects, processes, and exports observability data. Unlike Prometheus, which mainly focuses on metrics, OpenTelemetry provides a standardized way to instrument applications for all three types of observability data: logs, metrics, and traces.

OpenTelemetry is designed to be vendor-agnostic. This means you can instrument your applications once with OpenTelemetry and then send that telemetry data to any supported observability backend, which could be an open-source solution like Jaeger or Prometheus, or commercial platforms like Datadog, New Relic, Dynatrace, or Honeycomb.

So, for example, you can use OpenTelemetry to instrument your application – and then Prometheus can pull metrics from OpenTelemetry while other tools handle logs and traces.

What are OTLP Resource Attributes?

When OpenTelemetry collects data from applications, it does more than just gather raw telemetry data. It also provides context about that data. This context comes in the form of resource attributes, which describe where the data came from and what it relates to.

The 'resource' is the component (or entity) producing the data, while the 'attributes' are specific details about that resource.

Resource attributes are structured as pairs of information:

• The "key" is the name or identifier of the attribute (like service.name or host.id)

• The "value" is the specific information for that attribute (like payment-service or server-123)

Together, these key-value pairs identify and describe the specific component that's generating the observability data.

For example, if a payment processing service is sending metrics about transaction times, the resource attributes might include:

• service.name: "payment-service"

• service.version: "1.2.3"

• deployment.environment: "production"

These attributes tell you exactly which service, which version, and in which environment the data is coming from, providing context for interpreting the metrics, logs, or traces.

Resource attributes are not arbitrary. OpenTelemetry provides a standardized set of attribute names and formats that everyone should follow, similar to having an agreed-upon language for describing services and their properties.

For example, OpenTelemetry specifies that you should use service.name (not app_name or service_id) to identify your service. They've created these standardized naming conventions (called semantic conventions) so that:

1. All tools in the ecosystem can understand the same attributes

2. Engineers across different companies use consistent terminology

3. Observability data can be easily shared between different systems

You can still create your own custom attributes when you need something specific (like payment.provider for a payment service), but using the standard attributes whenever possible means your telemetry data will work better with existing tools and be more easily understood by other engineers.

Importance of OTLP Resource Attributes

Let’s say engineers want to monitor how long food deliveries take and whether there are delays in specific locations. Without resource attributes, OpenTelemetry might simply collect and report this metric like this:

delivery_time_seconds: 1800

This tells us that a delivery took 1,800 seconds, or 30 minutes, but nothing else. That’s useful, but it lacks context. Where did this happen? Which service handled it? If there was a delay in delivery and engineers wanted to investigate the cause, this alone would not help.

With OpenTelemetry’s resource attributes, the metric becomes more meaningful:

delivery_time_seconds: 1800
resource:
  service.name: "delivery-service"
  service.instance.id: "instance-456"
  cloud.region: "ng-west-2"
  deployment.environment: "production"
  customer.city: "Lagos"
  restaurant.id: "rest-789"

This tells us:

• The data came from the delivery service.

• The instance handling the request is "instance-456".

• It’s running in the ng-west-2 cloud region.

• The environment is Production (not testing or staging), and so on.

Now, engineers can answer more specific questions:

• Are deliveries slower in certain cities? (Filter by customer.city)

• Are certain restaurants taking longer to prepare food? (Filter by restaurant.id)

• Are delays only happening in a specific cloud region? (Filter by cloud.region)

• Are issues only happening in production or also in staging? (Filter by deployment.environment)

When issues arise, resource attributes allow engineers to quickly narrow down the source of problems. Rather than investigating every service, they can filter by specific attributes to focus their efforts.

How My Project Work Fits into All This

Many engineers use OpenTelemetry for data collection and then send metrics to Prometheus for storage, querying, and analysis.

But Prometheus does not natively support resource attributes in the same way as OpenTelemetry. Instead, it relies on labels to organize metrics. Since Prometheus traditionally has its own labeling system for metrics, integrating OpenTelemetry's resource attributes creates interesting UX challenges.

One key challenge is the cardinality explosion. Cardinality refers to the number of unique combinations of label values (or dimensions) that a metric can have. A "cardinality explosion" occurs when you add labels with many possible values. OpenTelemetry often includes many detailed attributes that, if directly converted to Prometheus labels, would create an overwhelming number of time series. This can slow down Prometheus dramatically or even cause it to crash.

The existing solution involves stuffing all resource attributes into a single JSON-encoded Prometheus label. While this prevents the cardinality explosion, it makes querying extremely cumbersome. Users have to use complex join operations and specialized query syntax to filter or aggregate based on these attributes.

This approach is technically functional but creates a poor user experience. My research aims to understand how users mentally model the transition from OpenTelemetry's rich attribute system to Prometheus's more constrained label system.

The research goals are to:

1. Understand how engineers currently use OpenTelemetry resource attributes with Prometheus

2. Identify pain points in the current integration between these systems

3. Discover user expectations for how resource attributes should be represented in Prometheus

This work is particularly important as more organizations adopt OpenTelemetry as their instrumentation standard while continuing to use Prometheus for metrics monitoring. Creating a seamless experience between these two popular open-source projects will help improve the overall observability ecosystem.

Conclusion

Observability in cloud native applications is clearly an interesting subject and important for building reliable, performant systems. The tools and concepts we've explored – metrics, logs, traces, Prometheus, and OpenTelemetry – form the foundation of modern observability practices.

As I continue my mentorship program, I'll share more insights about how these technologies work together and try to break them down from the perspective of a first-time learner.

Additional Resources

Learn more about:

1. OpenTelemetry

2. Prometheus

3. My UX research project

Rejection stings, especially when you’ve poured your heart and time into an application. Outreachy is competitive, and not everyone who applies will make it through.

So if you’ve found yourself on the other side of the selection list, don’t despair. The Open Source sky is wide enough for every bird to fly.

If you're truly passionate about contributing to open source and building a successful open source career, this article offers practical advice on how to pursue that path—whether you get into Outreachy or not.

Table of Contents

• Why You Were Not Selected

• Should You Reapply?

• Alternative Routes to Contributing to Open Source

• Keep Contributing to Open Source

Why You Were Not Selected

First, it’s important to understand the context. Outreachy receives hundreds of applications for a limited number of slots. The selection process is rigorous, and even highly qualified applicants may not be chosen due to factors beyond their control.

Note that this is just my perspective, drawn from personal experience and conversations with other past interns. It may not fully reflect the specific reasons why mentors or organizers might not select an applicant. But the factors I’ll discuss are worth considering and can help guide your future applications.

1. Project fit

Project fit is about more than just matching technical skills. I often advise applicants to choose projects that they’re passionate about. It’s not enough to only have the technical skills the project requires. Do your interests align with the project’s goals? Have you shown an understanding of its challenges? Are your contributions relevant to what the project actually needs?

Mentors look for candidates who don't just want an internship, but who genuinely care about the project's mission. They seek individuals who can see beyond the code to the broader impact of the open source initiative.

2. Contribution quality

Applicants are encouraged to start with smaller tasks and progress to more complex ones. But because contributions are tracked, some applicants may be tempted to focus on the quantity of their contributions rather than the quality.

If you were a mentor for a project focused on improving accessibility, whom would you choose: an applicant who has logged 10 contributions, all consisting of typo fixes in documentation? Or one who has made 2 contributions, including a comprehensive accessibility audit and a detailed report?

One thoughtful, high-quality contribution often outweighs several superficial ones because it demonstrates your potential to add real value to the project.

3. Overall application narrative

Your application is a story, not just a list of achievements.

• How compellingly do you explain your motivations?

• Do you demonstrate a long-term commitment to open source?

• Can you articulate your learning goals?

• Do you show potential for growth?

• How do you connect your past experiences to the project?

Mentors read hundreds of applications. Those that tell a coherent, passionate story are more likely to stand out.

4. The sheer volume of exceptional candidates

Sometimes, there are just so many exceptional applicants and not enough internship slots. It’s a tough decision for the mentors.

In this case, whether you’re selected or not is a matter of mathematical probability. So, if you are not selected, it doesn't mean you're not skilled or deserving enough. Understanding this can help you approach rejection with a growth mindset rather than self-doubt.

Should You Reapply?

"If at first you don't succeed, try, try, try again" — William Edward Hickson

Many successful Outreachy interns were not selected on their first try. I’m one of them. If you’re eligible and still passionate about the program, by all means, reapply.

Here’s how to strengthen your next application:

Start Early: Start exploring past Outreachy projects and building connections with mentors well before the application phase. Some communities (for example, Oppia, Wikimedia, Fedora, and Bioconductor) are regular Outreachy participants and are likely to participate in the next internship round.

Expand Your Skills: Use the time between application cycles to deepen your knowledge in areas that align with Outreachy projects, whether it’s coding, documentation, or community management.

A friend of mine, Karimot Isiaka, started learning about accessibility after discovering that the project I worked on during my Outreachy internship was focused on this area. Today, she’s one of the December 2024 interns working on a project centered around accessibility. Had she not taken the initiative to expand her skills and dive into accessibility, she likely wouldn’t have been prepared for this opportunity. Be like Karimot.

Build Relationships: Join project communities, participate in discussions, and contribute consistently. Mentors often notice applicants who’ve been active contributors.

Alternative Routes to Contributing to Open Source

Outreachy has played a significant role in introducing people from underrepresented groups to open source, providing mentorship, and offering a pathway to impactful contributions. But it’s just one route among many. Open source is a vast ecosystem, filled with opportunities to learn, grow, and even build a career.

Here are other ways to make an impact in open source:

1. Independent Contributions

One of the most direct ways to get involved in open source is by contributing independently to projects that align with your interests. You can:

• Go on GitHub or Gitlab and look for issues tagged as “good first issue” or “help wanted.”

• Contribute to documentation, test cases, or bug fixes.

• Participate in Hacktoberfest, an annual celebration that encourages people to contribute to open source projects while earning rewards and gaining experience.

Independent contributions allow you to build a portfolio and demonstrate your skills in a practical context, which can be just as impactful as participating in a formal program. Here’s a helpful article by Fanny Nyayic about how to get started as a beginner open source contributor.

2. Other Open Source Internship Programs

If you’re bent on the internship route, there are other structured open source programs similar to Outreachy. Some of them include:

1. Google Summer of Code (GSoC): GSoC is a global program that introduces students and new open source contributors to real-world software development. Participants work on a project with an open source organization, receiving mentorship, a stipend, and experience contributing to the open source community.

2. Google Season of Docs: This program connects technical writers with open source organizations to improve their documentation. Writers work on tasks such as user guides, tutorials, or API documentation, enhancing the usability and accessibility of open source projects.

3. LFX Mentorship: Offered by the Linux Foundation, LFX Mentorship provides hands-on experience working with Linux Foundation projects. It supports contributors in learning about open source technologies, networking, and growing their technical expertise through paid mentorship opportunities.

4. MLH Fellowship: The Major League Hacking (MLH) Fellowship is a remote program where participants build and contribute to open source projects in areas like software development, systems design, or data science, while collaborating with peers and receiving mentorship from industry experts.

5. Season of KDE: This mentorship program is run by the KDE Community, an open source organization focused on free software projects. Participants work on KDE initiatives such as software development, design, documentation, or community-building activities.

6. AsyncAPI Mentorship Program: The AsyncAPI Mentorship Program offers contributors opportunities to work on improving AsyncAPI tools and documentation. Participants collaborate on projects like software libraries, community initiatives, design, or technical documentation while learning open source best practices.

7. Summer of Bitcoin: This program introduces university students to Bitcoin and open source development. Participants work with experienced mentors on projects that contribute to the Bitcoin ecosystem, focusing on coding, documentation, or research initiatives.

3. Paid Opportunities in Open Source

Open source contributions can open doors to paid opportunities. Here are some ways to monetize your efforts:

• Sponsorship Platforms: Programs like GitHub Sponsors and OpenCollective enable contributors and maintainers to receive financial backing for their work.

• Google Open Source Peer Bonus Program: The Google Open Source Peer Bonus program recognizes and rewards contributors for their impact on open source projects.

• Open Source Job Hubs: Platforms like Open Source JobHub, OSSJobs, and Open Source Design curate paid opportunities within the open source ecosystem and connect contributors with roles that align with their skills.

• Bounty Programs: Many open source projects offer bounty programs where contributors can earn money for completing specific tasks, fixing bugs, or adding features. The AsyncAPI Bounty Program is an example. Platforms like Bountysource, IssueHunt, and Gitcoin also connect contributors with paid tasks in open source

• Full-Time Roles: Many tech companies hire developers to focus exclusively on maintaining or enhancing open source projects they rely on or sponsor.

4. Non-Code Contributions

Non-code contributions are an underrated yet valuable way to get involved. If you’re a non-technical person, you can contribute to open source in any of the following ways:

• Design: Creating UI/UX designs or social media graphics for open source projects.

• Community management: Moderating forums, organizing meetups, or managing social media. Amarachi Johnson has a helpful article here on contributing to open source projects as a community manager.

• Advocacy: Writing articles, giving talks, or creating tutorials about the project. Christine Belzie has a helpful article here on how technical writers can contribute to OSS.

5. Personal Projects

If you’re passionate about solving a particular problem, consider starting your own open source project. That side project you’re working on? You could make it open source. Invite other people to contribute. Build an open source community around this project you care about. Who knows? You could build the next freeCodeCamp.

Keep Contributing to Open Source

Rejection hurts, but it’s not the end of the road. Many accomplished contributors faced rejection at some point. Some didn’t make it into Outreachy or GSoC but went on to become project maintainers, speakers, or leaders in the open source space.

If you haven’t gotten into Outreachy, take a moment to regroup and then try again. And while you’re at it, explore other opportunities. Don’t give up. Rejection is just a step in the journey. Keep pushing forward, and you'll find your place in the open source world.

A web accessibility audit helps you identify and fix issues that prevent users from interacting with your website effectively. In this guide, you’ll learn how to perform a web accessibility audit and improve your site’s usability.

Table of Contents

• What is Web Accessibility?

• What is a Web Accessibility Audit?

• What to Do Before the Audit

• How to Audit Your Website

• What to Do After the Audit

• Accessibility is an Ongoing Process

What is Web Accessibility?

Web accessibility means that websites and web applications are designed and developed so that people with disabilities can use them. This includes individuals with visual, auditory, motor, cognitive, and neurological disabilities. An accessible website provides a better user experience for all users, regardless of their abilities.

What is a Web Accessibility Audit?

A web accessibility audit is the process of evaluating a website or web application to determine how easily people with disabilities can use it. This evaluation is done against established standards set by the World Wide Web Consortium (W3C). These standards, known as the Web Content Accessibility Guidelines (WCAG), provide the criteria for evaluating a website's accessibility.

An accessibility audit helps you identify barriers that prevent people with disabilities from fully using or interacting with your site. By the end of the audit, you’ll have a comprehensive report that details the issues found and actionable steps to improve your site's accessibility.

What to Do Before the Audit

Before diving into the actual audit, there are a few preparatory steps you need to take to set the foundation for a thorough and organized accessibility review. Here's what you need to do:

1. Familiarize Yourself with Accessibility Guidelines

The first step in any accessibility audit is understanding the rules you're auditing against. Familiarizing yourself with these guidelines will help you understand what to look for and what kind of changes might be necessary to improve your site's accessibility.

The Web Content Accessibility Guidelines (WCAG) provide detailed recommendations on how to make websites more accessible to people with disabilities. It is versioned, with the WCAG 2.2 being the most updated version. The guidelines are divided into three levels of conformance:

• Level A: The minimum requirements for accessibility.

• Level AA: Addresses more common barriers for disabled users.

• Level AAA: The highest and most rigorous level of accessibility.

For a start, you should aim for Level AA compliance.

2. Define the Goal of Your Audit

Why are you doing the audit in the first place, and what do you hope to achieve? You goal could be to:

• Know where you are in terms of accessibility.

• Generate a voluntary product accessibility template (VPAT).

• Identify what issues need to be remediated.

Your goal will determine what approach you take to perform the audit.

3. Define the Scope of Your Audit

Next, decide what parts of your website you’ll be auditing. While it's ideal to audit the entire site, this might not always be feasible due to time or resource constraints. In that case, focus on key pages and features that are critical for user interaction.

4. Gather Your Tools

To conduct a thorough web accessibility audit, you'll need a combination of automated and manual testing tools.

For automated testing, some popular tools include:

• WAVE

• Axe DevTools

• Lighthouse

• Color contrast analyzers

For manual testing, you'll need:

• A keyboard (to test keyboard navigation).

• Screen readers like JAWS, NVDA, or VoiceOver.

• Different browsers to check compatibility.

• Ideally, a group of test participants, especially individuals with disabilities, to provide real-world feedback.

5. Create an Accessibility Checklist

Based on the WCAG guidelines, create a checklist of specific items to verify during your audit. This checklist will serve as your roadmap, ensuring that you don’t miss any critical components.

Having a checklist based on WCAG standards ensures consistency in your audit and gives you clear, actionable steps to follow. It also allows you to track your progress and document issues for later review.

How to Audit Your Website

Now it’s time to conduct the actual audit. A good approach is to start with a quick test using an automated tool, followed by a thorough manual review to catch issues that automation might miss.

Step 1: Run an Automated Scan

For the automated scan, you can use WAVE, axe DevTools, Lighthouse, or a combination of these for a more comprehensive assessment. Use multiple tools to catch a broader range of accessibility issues and provide a more well-rounded analysis.

Using WAVE

1. Go to wave.webaim.org.

2. Enter the URL of the website you want to check.

Alternatively,

1. Install the WAVE browser extension.

2. Go to the page you want to audit.

3. Right-click on the page to open the context menu.

4. Click “WAVE this page” to scan your page.

   

5. WAVE will generate a report showing:

   • Errors (red icons)

   • Alerts (yellow icons)

   • Features (green icons)

   • Structural elements (blue icons)

   • HTML5 and ARIA elements (purple icons)

     

6. Click on each icon to get more information about the issue or feature.

Using axe DevTools

1. Install the axe DevTools extension for your browser.

2. Navigate to the web page you want to test.

3. Open your browser DevTools (F12 or Cmd+Option+I)

4. Go to the "axe DevTools" tab.

   

5. Click "Full Page Scan" to start the accessibility check.

6. Review the results. They are categorized by severity (Critical, Serious, Moderate, Minor).

7. Each issue includes details on:

   • What the problem is

   • Why it matters

   • How to fix it

   • Which WCAG success criteria it violates

Using Lighthouse

1. Open your browser DevTools (F12 or Cmd+Option+I).

2. Go to the "Lighthouse" tab.

3. Select "Accessibility" under "Categories" (you can select others too).

   

4. Click "Analyze page load".

5. Review the accessibility score and specific issues found.

6. Each issue links to more detailed explanations and how to fix them.

Step 2: Conduct a Manual Test

Manual testing complements automated tools by checking issues that can’t be automatically detected. It involves simulating how users with disabilities would interact with your website. Here are some key areas to focus on during manual testing:

1. Keyboard Navigation

Many users rely on a keyboard to navigate the web, either due to mobility impairments or because they use assistive technologies like screen readers. To test this:

• Ensure all interactive elements (links, buttons, forms) can be accessed using the Tab key.

• Use the Enter or Spacebar to activate elements.

• Check for keyboard traps (places where a user can get stuck and can’t navigate out).

2. Screen Reader Compatibility

Screen readers convert on-screen content into speech or Braille. To test screen reader accessibility:

• Install a screen reader like NVDA (for Windows) or VoiceOver (for macOS).

• Navigate through the website using only the screen reader. Check whether the content is read in a logical order and all elements are properly labeled.

• Pay attention to issues like missing or incorrect alt text for images, improper headings structure, and unlabeled buttons.

3. Text Alternatives

Check that non-text content such as images, videos, and icons have appropriate text alternatives. For example:

• Images should have descriptive alt text that conveys their purpose or function.

• Videos should include captions and transcripts to ensure accessibility for users with hearing impairments.

Step 3: Review Semantic HTML and ARIA Usage

Semantic elements like <header>, <nav>, <article>, and <footer> help screen readers understand the structure of a page. Accessible Rich Internet Applications (ARIA) attributes can be used to enhance accessibility for dynamic content. However, it’s important to use ARIA sparingly and only when necessary, as incorrect usage can lead to more problems.

Here are some best practices:

• Use semantic HTML wherever possible before resorting to ARIA.

• Ensure that ARIA roles, states, and properties are correctly implemented. Misusing ARIA can confuse users and screen readers.

Step 4: Document Issues

Once you’ve completed both automated and manual testing, it’s time to document the accessibility issues you’ve discovered. Categorize the issues by their severity:

• Critical: Issues that block users from accessing essential features, such as non-functional navigation or forms.

• Moderate: Issues that degrade the user experience, like poor color contrast.

• Minor: Minor violations that don’t significantly impact the user experience but should still be addressed, such as misused ARIA attributes.

Use a spreadsheet or project management tool like GitHub Issues to document the issues. You could also use the WCAG-EM report tool developed by the W3C Web Accessibility Initiative (WAI).

In your report, be sure to include:

• The page where the issue occurs.

• A description of the problem.

• WCAG success criteria it violates.

• Suggestions for how to fix the issue.

What to Do After the Audit

You’re done with your audit. You now have a detailed accessibility report with issues that you’ve identified. What do you do next?

1. Implement and Test Fixes

The next step is to work with your development team to implement the fixes. Ideally, you should aim to resolve all identified issues. However, if you're working under time constraints, you may want to prioritize issues that are easier to fix but still have a significant impact on accessibility.

After making these changes, rerun your accessibility audits—both automated and manual—to verify that the issues have been successfully resolved.

2. Establish Accessibility Guidelines

Your accessibility efforts would go to waste if new developers on your team introduced accessibility issues to your website. To prevent this, create a comprehensive document outlining your accessibility standards. This document should detail the best practices your team will follow moving forward. This way, all future updates or changes maintain the accessibility improvements you've made.

Accessibility is an Ongoing Process

Performing a web accessibility audit is an important step toward making your website more inclusive. But does that mean your job is done, and you can sit back and relax? Not quite. Accessibility isn't a one-time task. It's an ongoing process.

As you add new features or content, you'll need to continuously test and improve your site to maintain accessibility standards. This doesn't just benefit users with disabilities, it enhances the overall user experience for everyone.

Consistently prioritizing accessibility leads to a more user-friendly, functional, and inclusive website.