My CPACC journey

Ilknur Eren — Sat, 25 Jul 2026 14:42:26 +0000

The Certified Professional in Accessibility Core Competencies (CPACC) is a credential offered by the International Association of Accessibility Professionals (IAAP). It is designed for people who work in or around accessibility, engineers, designers, and others.
The exam covers three broad areas: disabilities, accessibility and universal design, and accessibility standards and laws.

Why I decided to take it

I have spent most of my career as an engineer with a focus on accessibility. I write code. I help teams build things that work for everyone. I write articles educating on accessibility standards. I knew the WCAG guidelines and semantic HTML. I knew how to test with a screen reader. I live and breathe accessibility.

Taking the CPACC felt like a chance to solidify the years of accessibility work.

What studying actually looked like

I spent several months preparing for the exam last year. I worked through the IAAP Body of Knowledge, read research, and took practice tests. I watched youtube tutorials and completed the CPACC prep course offered by Deque University.

The technical material felt familiar at first. Assistive technology, accessibility standards, barrier types, I had touched most of this on m. But the exam goes deeper than surface familiarity. I had to understand how different types of assistive technology work, not just that they exist.

The history and policy sections were where things really opened up for me. Studing for the CPACC exam, I realized how much context I had been missing.

The exam itself

The CPACC test covers a wide range of topics. Some questions put you in real-world scenarios and ask you to apply what you know. Others test precise definitions and legal details.

I felt prepared walking in, and the exam still challenged me. That is a good thing. A credential that is easy to get is not worth much.
After months of studying, I passed. I am now a CPACC certified engineer.

But more than the credential, I walked away with a broader view of accessibility. I understand more about the lived experiences of people with disabilities. I understand more about the assistive technologies they rely on, the legal and policy frameworks that shape what companies are required to do — and what they should do even when they are not required to.

That last part matters. Requirements set a floor. Good accessibility work aims higher.

Keeping the certification

The CPACC is not a one-time achievement. Like many professional credentials, it requires ongoing education to maintain. it requires attending accessibility conferences, taking courses. I need to earn continuing education credits to keep my certification active.

Honestly, I see that as a feature. Accessibility is a living field. Standards evolve. Technology changes. New research shapes best practices. Staying certified means staying current.

Should you take it?

If you work in accessibility, I think the CPACC is worth pursuing. Not just for the credential, but for what the process of studying teaches you.

Technical skills alone are not enough to do this work well. You need context. You need history. You need to understand the people your work is meant to serve.

The CPACC exam pushed me toward all of that. I truly feel like I am a better engineer because of it.

Accessible Form Labels

Ilknur Eren — Sat, 11 Jul 2026 00:00:15 +0000

Labels are a foundational part of any accessible form. Without properly implemented, users who rely on screen readers have no way to understand what a field is asking for. A label does two things: it tells the user what a field is for, and it connects that meaning to the input in the code so assistive technology can announce it. There are a number of basic form label accessibility rules all developers should follow to build accessible forms.

Use the `<label>` element

Every input needs a visible, programmatic label. The most reliable way to label an input is with the HTML element, linked to the input using matching for and id attributes. Example is below:

<label for="email">Email address</label>
<input type="email" id="email" name="email">

In the example above, the first line is the label of the form field. With the proper for and id, we can programmatically link the tag to the tag. Additionally to linking the label, when the for and id values match, clicking or tapping the label text also moves focus to the input.

When a visible label isn't practical

Some designs use a search bar with a button, or a compact inline form, where a visible label would feel visually cluttered. In those cases, use aria-label or aria-labelledby to provide a label programmatically without showing it visually.

<!-- aria-label: attach a label string directly to the input -->
<input type="search" aria-label="Search the site">
<!-- aria-labelledby: point to an existing element on the page by its id -->
<h2 id="signup-heading">Create your account</h2>
<input type="email" aria-labelledby="signup-heading">

Use aria-labelledby when label text already exists on the page. It references that text by id, so screen readers announce it without duplication.

Placeholder text is not a label

This is one of the most common labeling mistakes. Placeholder text disappears the moment someone starts typing, screen readers don't reliably announce it as label text, and its low contrast often fails WCAG minimums. It can hint at expected format (like "MM/DD/YYYY"), but it must never stand in for a real label.

<!-- Wrong: no label, placeholder only -->
<input type="text" placeholder="Full name">
<!-- Right: visible label + placeholder as a format hint -->
<label for="dob">Date of birth</label>
<input type="text" id="dob" name="dob" placeholder="MM/DD/YYYY">

Marking required fields

If a field is required, mark it in two ways: in the code and in the visible label.
Add required (or aria-required="true") to the input so assistive technology announces it. Then add visible text — like "(required)" — next to the label so sighted users also see it.

<label for="name">Full name (required)</label>
<input type="text" id="name" name="name" required>

A red asterisk alone is not sufficient. Screen readers may not announce it, sighted users may not know what it means without a legend, and color alone never conveys meaning in an accessible way. If you do use an asterisk, include a visible legend near the top of the form — for example, "Fields marked with * are required" — and wrap the asterisk in so screen readers skip it and rely on the required attribute instead.

<p>Fields marked with <span aria-hidden="true">*</span> are required.</p>
<label for="phone">Phone number <span aria-hidden="true">*</span></label>
<input type="tel" id="phone" name="phone" required>

Keep labels close to their inputs

Sighted users scan forms by proximity. Labels should appear directly above or immediately to the left of their input, not below and not far away. This also helps users who zoom in on a page, since distant labels may scroll out of view.

Label groups of related inputs

For radio buttons, checkboxes, and other grouped inputs, use

<fieldset> and <legend> to label the group as a whole. Each individual option still needs its own <label>.
html
<fieldset>
  <legend>Preferred contact method</legend>
  <input type="radio" id="contact-email" name="contact" value="email">
  <label for="contact-email">Email</label>
  <input type="radio" id="contact-phone" name="contact" value="phone">
  <label for="contact-phone">Phone</label>
</fieldset>

Without <fieldset> and <legend>, a screen reader user hears "Email, radio button" with no context about what they're choosing.

Conclusion

Accessible forms are not an edge case or a nice-to-have, they are a baseline requirement. The labeling practices covered in this article are some of the most impactful changes you can make, because labels are the foundation everything else builds on. A form without proper labels fails before a user even has a chance to fill it out.

DEV Community: Ilknur Eren