I am offering accessibility remediation and audit services.

Schedule a meeting -> https://calendly.com/stefanynewman/discovery-call

What makes me stand out from the competition?

1. I have worked as an Accessibility Subject Matter Expert at major companies, including Microsoft, Airbnb, and Paramount.
2. As an experienced front-end developer, I bring a unique and valuable skill set: I can not only audit a site for accessibility issues but I can also fix the code myself or recommend precise, actionable fixes directly within the codebase.
3. I hold the CPWA certification (Certified Professional in Web Accessibility), which is the highest designation available for an accessibility professional.
4. I am ready to start contributing immediately
5. I have the major screen readers and devices needed to perform a comprehensive accessibility audit, such as JAWS, VoiceOver, TalkBack and NVDA.
6. I never outsource my accessibility work, ensuring your company’s secrets and proprietary information are safe and secure with me.
7. I can audit websites and digital properties in multiple languages: English, Bulgarian, and Russian.

How I can help your digital agency:

• Most freelancers work with clients after they get home from work, leaving them exhausted and prone to making mistakes. On the other hand, being an independent contractor is my full-time job, so I can be relied upon, not only to produce quality work, but also to communicate as frequently as needed.
• If your agency website is not accessible, yet you advertise accessibility services, there is nearly 0% chance that you will be hired by clients who need to comply with accessibility. Would you trust a lung doctor who smokes? You are probably constantly losing clients without knowing it, since it takes pressing a few buttons to evaluate general website accessibility.
• If you have clients that receive Federal funding, such as some universities and medical providers, they must comply with Section 508 (WCAG 2.0). However, hiring a full-time accessibility specialist for one or two clients can be prohibitive — hence hiring an independent contractor per a project is much more affordable.
• If you advertise that you provide accessibility services, but don’t have a specialist on staff, it’s more affordable to hire outside help.
• During the Discovery Process with a new client, if you need to write down the accessibility requirements, you would need that done by a specialist, not just a project manager or a sales person.
• If you need accessibility training for your Engineering and Design staff.
• If your clients have any presence in the European Market, then they need to comply with the European Accessibility Act (EAA)
• If you need help writing a VPAT(Voluntary Product Accessibility Template) / ACR (Accessibility Conformance Report).

How I can help your Product:

• If you need training for your testers. If your QA testers are not accessibility certified, they do not know how to test for it. It’s like asking someone who hasn’t gone to medical school to check your health.
• If you need to confirm your product’s accessibility.
• If you need to test with JAWS, but don’t want to pay for a subscription (it costs almost 1k a year).
• If you need someone US based. Hiring offshore accessibility specialists increases the risk of trade secrets being revealed and weakens application security.
• If you need an accessibility roadmap for your product, divided by sprints for your Quarterly Planning
• If you want to sell your product to an entity that receives Federal funding, then the procurement process requires an Accessibility Conformance Report (commonly misnomered as a VPAT) of your offering.

Testimonials from previous employers:

“Stefany helped us through three large accessibility audits, taking the reins on bug fixing, investigating, and documenting. I hope to work with [her] again!” — Chad Schulz, Principal Software Engineering Manager at Microsoft

“Stefany’s passion for accessibility shone through in her work.” — Diane Ko, Staff Engineer at Airbnb

I only work with 3 clients per a quarter, so book your free consultation today!

Portfolio:

Udemy link — https://www.udemy.com/user/stefany-newman/

Recent Conference Talk — https://docs.google.com/presentation/d/1rIej0xxaqsYTD1ttdxjXRP35jOKZ_uVuiYEgs3vO9P4/edit

Hand-coded accessible website — https://pointyendfencing.com/ | Code — https://github.com/stefany-newman/accessible-fencing-website

Accessible Image Slider (hand-coded) — https://github.com/stefany-newman/accessible-image-slider

VPAT / ACR — https://github.com/stefany-newman/accessible-image-slider/blob/main/Accessibility%20Conformance%20Report.md

Summary: Do not follow the APG’s version of a carousel literally. Make sure to code it depending on its own architecture. Use aria-roledescription to give the container a human readable name and don’t clutter the DOM with redundant ARIA. Check out the finished slider.

Nearly every website has images. One of the most difficult projects in accessible engineering is dealing with just about anything that has JavaScript and pictures. And if your website is an e-commerce one, then you definitely need image galleries — hence the point of this article.

But where could we find an accessible slider? We could copy the APG’s implementation of it, but there are two main problems:

1. Their code is old (they use var bindings — imagine going to the restroom and finding out there are newspapers instead of toilet paper — it would do the job, but at what cost?)
2. They only have 2 different instances of a slider — ones with bells and whistles — what if you need something simpler?

Defining project requirements

Functions:

• One image showing at a time;
• Next / previous graphic buttons
• Upon reaching the end of the “next” image, the first one is shown;
• Upon reaching the end of the “previous” image, the last one is shown;
• Navigation dots
• When the user activates either a dot or the next / previous buttons, the current dot becomes active (aria-current=”true”)

Accessibility requirements:

• All controls must be keyboard operable;
• All controls must remain visible while the user is in Forced Colors Mode (formerly known as Windows High Contrast Mode);
• 3:1 contrast to adjacent colors (unless we add medium sized text, then the contrast has to be 4.5:1);
• The component must scale without a horizontal bar appearing, while the browser is zoomed in up to 400%;
• All content images must have alt text;

WCAG Success Criteria to conform to:

1. 1.1.1 Non-text Content
2. 1.3.1 Info and Relationships
3. 1.3.2 Meaningful Sequence
4. 1.4.1 Use of Color
5. 1.4.10 Reflow
6. 1.4.11 Non-text Contrast
7. 2.1.1 Keyboard
8. 2.4.7 Focus Visible
9. 2.4.12 Focus Not Obscured (Enhanced)
10. 2.5.5 Target Size (Enhanced)
11. 3.3.2 Labels on Instructions
12. 4.1.2 Name, Role, Value

WCAG Success Criteria to conform to, depending on the content:

1. 1.4.5 Images of Text (if the images contain burnt-in text, they must conform to 1.4.5).

Coding the HTML

<section aria-roledescription="image slider" aria-labelledby="gallery-heading">
    <! - Slider code here →
</section>

Landmark or no landmark?

Contrary to popular belief, <section> doesn’t have any semantic meaning, unless it has an accessible name, then it becomes a region. However, you could conform to the WCAG without making every <section> a region. In fact, if all your sections are regions, it will make the website harder to browse with screen readers since it would clutter the landmarks list.

If the parent page of the gallery is titled “Gallery”, then there is no need to add a semantic meaning to the container, especially if you have a visible heading.

<section aria-roledescription=”image slider” aria-labelledby=”gallery-heading”>
     <h1 id=”gallery-heading”>Gallery</h1>
</section>

We start by creating a section and giving it an aria-roledescription of “image slider”. The attribute aria-roledescription is used on group or region landmarks to give screen readers a hint as to what the content represents. The attribute aria-labelledby is used to name the section, hence giving it an implicit role of region.

<! - Next Button →
<button type="button" aria-label="Next Image">
    <svg aria-hidden="true">…</svg>
</button>
<! - Previous Button →
<button type="button" aria-label="Previous Image">
    <svg aria-hidden="true">…</svg>
</button>

Next and previous buttons added. Notice the ARIA:

• aria-label gives the buttons a string to be announced by screen readers, since their contents are just SVG arrows;
• We hide the SVG arrows from screen readers with aria-hidden. The attribute is commonly used to hide elements from screen readers, but leaves them visible to sighted users.

<div id="gallery-images">
    <img src="example-image-1.png" id="image1" alt="Image 1" >
    <img src="example-image-2.png" id="image2" alt="Image 2" hidden>
    <img src="example-image-3.png" id="image3" alt="Image 3" hidden>
    <img src="example-image-4.png" id="image4" alt="Image 4" hidden>
</div>

Whenever we are writing JavaScript code that hides and shows content, we first must determine how to hide the elements, because there are numerous ways to do it, and it makes it easier to define it beforehand. In this case, we will hide the images with the hidden attribute.

<ol role="list">
  <li>
     <button type="button" aria-current="true" aria-labelledby="image1"></button>
  </li>
  <li>
      <button type="button" aria-current="false" aria-labelledby="image2"></button>
  </li>
  <li>
      <button type="button" aria-current="false" aria-labelledby="image3"></button>
  </li>
  <li>
      <button type="button" aria-current="false" aria-labelledby="image4"></button>
  </li>
</ol>

We use role=”list” so that the list is announced properly on VoiceOver on Safari — since we are using list-style-type: none to style the dots, it sometimes makes the screen readers forget they are dealing with a list. aria-current is used to denote the currently active dot / image, and aria-labelledby labels each dot with the alt text of the image.

There are many ways to name dot navigation buttons. Some people use “Slide 1 of 4” in the accessible name, some people just use a static string, it depends on your component and its architecture. I chose to name the dots after the images, since at this time of writing (July 1), the alt text of the current image is not announced on next / previous with aria-live. This was a deliberate architectural decision on my part.

This is the final HTML (with classes and IDs):

<section class="gallery-section" aria-roledescription="image slider" aria-labelledby="gallery-heading">
    <h1 id="gallery-heading">Gallery</h1>
    <div id="gallery-container" class="gallery-container">
        <div class="next-prev-controls" id="next-prev-controls">
            <button type="button" id="next" class="next" aria-label="Next Image">
                <svg aria-hidden="true" xmlns="http://www.w3.org/2000/svg" viewBox="0 -960 960 960">
                    <path d="M647-440H160v-80h487L423-744l57-56 320 320-320 320-57-56 224-224Z"/>
                </svg>
            </button>
            <button type="button" id="prev" class="prev" aria-label="Previous Image">    
                <svg aria-hidden="true" xmlns="http://www.w3.org/2000/svg" viewBox="0 -960 960 960">
                    <path d="m313-440 224 224-57 56-320-320 320-320 57 56-224 224h487v80H313Z"/>
                </svg>
            </button>
        </div>
        <div id="gallery-images" class="gallery-content">
            <img src="images/example/example-image-1.png" class="gallery-image" id="image1" alt="Image 1" >
            <img src="images/example/example-image-2.png" class="gallery-image" id="image2" alt="Image 2" hidden>
            <img src="images/example/example-image-3.png" class="gallery-image" id="image3" alt="Image 3" hidden>
            <img src="images/example/example-image-4.png" class="gallery-image" id="image4" alt="Image 4" hidden>
        </div>
        <div id="dot-navigation" class="dot-navigation">
            <ol role="list">
                <li>
                    <button type="button" class="dot" aria-current="true"  aria-labelledby="image1"></button>
                </li>
                <li>
                    <button type="button" class="dot" aria-current="false" aria-labelledby="image2"></button>
                </li>
                <li>
                    <button type="button" class="dot" aria-current="false" aria-labelledby="image3"></button>
                </li>
                <li>
                    <button type="button" class="dot" aria-current="false" aria-labelledby="image4"></button>
                </li>
            </ol>
        </div>
    </div>
</section>

Stay tuned for parts 2 and 3.

Qué hacer: Permitir el uso del teclado

Permitir el uso del teclado con el botón implica dos cosas:

1. Los usuarios deben poder seleccionar el botón pulsando la tecla Tab…
2. …y al pulsar la barra espaciadora o Intro se debe activar, en este caso, ocultando o mostrando la contraseña.

Sencillo, ¿verdad?

✅ Tanto Google como Microsoft utilizan una casilla de verificación para controlar el desbloqueo de contraseñas, lo cual está bien, ya que las casillas de verificación se pueden manejar con el teclado de forma predeterminada.

Qué no hacer: Utilizar un ancla o un div clicable como control de activación

Cada vez que audito un sitio web y llego a su formulario de inicio de sesión, compruebo inmediatamente el HTML del botón para desvelar la contraseña y, en 9 de cada 10 casos, utiliza un enlace de ancla o un div. Es horrible.

❌ Ejemplo de un formulario de inicio de sesión que utiliza un div clicable como control desencadenante para su función de desvelar contraseña.

El uso de un elemento que no sea un botón plantea muchos problemas:

1. Es probable que el control no se pueda manejar con el teclado, lo cual es el mínimo exigido para cumplir con los requisitos de accesibilidad.
2. Para que <a> sea enfocable, es necesario asignarle una URL que genere esta estructura confusa “a href=”#”.
3. Otro efecto secundario negativo de utilizar <a> para un botón es que, aunque se programe toda la funcionalidad desde cero, el control seguirá apareciendo como un enlace si el usuario tiene activado el modo de alto contraste de Windows.

En su lugar, utilizar el elemento botón, que tiene características de accesibilidad integradas, como la activación con la barra espaciadora/Intro, la capacidad de enfoque y se muestra como un botón en el modo de alto contraste de Windows (asegúrate de utilizar border: transparent en lugar de border:none).

Si no puedes utilizar el elemento button, como último recurso, replícalo utilizando la guía de prácticas de autoría ARIA. Pero recuerda, hazlo solo si no tienes otra opción, porque es como tener que usar un periódico como papel higiénico.

Qué no hacer: Alternar los atributos aria-label y aria-pressed

Si no se utiliza una casilla de verificación, la mayoría de los desarrolladores utilizan un botón de alternancia con una aria-label como nombre accesible. Esto está bien, pero alternar los valores de ambos atributos es una mala práctica.

Personalmente, siempre me siento incómodo cuando me encargan cambiar los valores de la aria-label ya que considero que los nombres son algo semipermanente y a los lectores de pantalla no les gustan nada los nombres accesibles dinámicos.

Por el contrario, los atributos de estado como aria-pressed están pensados para ser dinámicos, por lo que cambiar sus valores no solo es lo esperado, sino que los lectores de pantalla lo admiten perfectamente.

Cambiar ambos solo provoca caos. Algunos lectores de pantalla no anunciarán el nuevo nombre, o anunciarán el nuevo nombre con el estado antiguo y viceversa.

Qué hacer: Elegir un nombre significativo y accesible

La mayoría de los botones de contraseña suelen ser simplemente un botón con un icono. Por lo tanto, es fundamental elegir el nombre accesible adecuado para que los lectores de pantalla puedan anunciar al usuario qué función tiene el control.

No te equivocarás si nombras tus botones “Mostrar contraseña” o “Alternar visibilidad de la contraseña”, siempre y cuando los combines con un marcador de estado como aria-pressed.

✅ La página para crear una cuenta de HP tiene un excelente ejemplo de un botón gráfico de contraseña con un nombre accesible adecuado. Un usuario ciego que utilice un lector de pantalla puede comprender inmediatamente para qué sirve el botón.

❌ Cuando un botón no tiene un nombre accesible, los lectores de pantalla suelen anunciar solo “button”, lo que resulta inútil para un usuario ciego.

Qué no hacer: Reducir el área objetivo a menos de 44 x 44 píxeles

Quizás estés pensando “Pero Stefany, el criterio de éxito 2.5.8 AA de las WCAG exige que el área objetivo o el espaciado sea de al menos 24 x 24 píxeles”. ¡Es cierto! Pero cuando se trata del tamaño de los objetivos o controles, tiendo a diseñarlos tan grandes como sea posible, hasta 44 píxeles, por las siguientes razones:

1. Incluso el criterio de éxito mencionado anteriormente sugiere que las áreas objetivo tengan un tamaño mínimo de 44 x 44 píxeles para “enlaces y controles importantes”.
2. En realidad, las WCAG recomiendan ceñirse a un tamaño mínimo de 44 x 44 píxeles, pero dado que el criterio de éxito para la recomendación es triple A, muchos profesionales de la accesibilidad lo ignoran por completo, lo cual es un error.
3. Las WCAG subrayan que debemos intentar implementar los criterios de éxito triple A en la medida de lo posible, y hacer los controles un poco más grandes es fácil.
4. Uno de los líderes en accesibilidad, Apple, también recomienda un tamaño mínimo de 44 x 44 píxeles*.
5. Los controles de mayor tamaño sirven principalmente para ayudar a las personas con temblores a activarlos, independientemente de si utilizan los dedos o el ratón. Pero, además, ayudan a las personas cuando se producen sacudidas mientras utilizan el teléfono, como en un viaje en autobús con baches, un terremoto o un concierto.

Si hay suficiente interés, estaría encantada de escribir un artículo en profundidad sobre por qué prefiero los botones más grandes y las ventajas que tienen.

✅ El control para mostrar la contraseña de la Asociación Americana de Esclerosis Múltiple tiene un tamaño de 85,96 x 45 píxeles, lo que facilita su activación. Un síntoma común de la esclerosis múltiple son los temblores en las manos.

Qué no hacer: Utilizar un icono de bajo contraste

Si utilizas un botón gráfico, debes tener cuidado de que el icono no se pierda en el diseño del sitio web. Una práctica habitual es que esos iconos sean grises, lo cual está bien, pero la mayoría de los sitios web tienen un fondo blanco, lo que hace que la mayoría de esos controles incumplan las directrices de contraste de color.

❌ El botón gráfico de Ryan Air no cumple con los requisitos de contraste de color, ya que solo tiene un contraste de 1,69:1 con el fondo blanco. Las WCAG exigen una relación de 3:1 para los controles de formulario.

Esto no significa que nunca se deba utilizar el color gris sobre un fondo claro, sino que se debe aplicar un tono más oscuro para que el contraste de color sea de 3:1.

Conclusión

Ninguna interfaz de usuario será accesible para todos, sin importar cuánto tiempo y esfuerzo se invierta, simplemente porque los seres humanos somos únicos. Si nos ceñimos al menos a unas sencillas normas de accesibilidad, podemos garantizar que una gran parte de los usuarios disfrutarán de una experiencia buena y accesible.

Veo muchos artículos y componentes que pretenden enseñar a la gente cómo programar el botón o enlace “perfecto”, lo cual es imposible. Pero pensemos en los componentes “mostrar contraseña” como el papel higiénico; es preferible un papel higiénico de una sola capa a ninguno, pero una persona preferiría sin duda uno de dos capas.

*Técnicamente, las Directrices de interfaz humana de Apple recomiendan 44 x 44 puntos, no píxeles, para adaptarse a sus pantallas retina. Sin embargo, el mínimo de su definición de 1 punto es 1 píxel.

Do: Make it keyboard operable

Making the button keyboard operable means 2 things:

1. Users must be able to focus the button by tabbing to it…
2. …and pressing Spacebar or Enter should activate it, in this case, it should mask/unmask the password.

Simple, right?

Don’t: Use an anchor or a clickable div as the trigger control

Whenever I am auditing a website and reach their sign-in form, I immediately check the HTML of the unmask password button, and 9 times out of 10, it’s using an anchor link or a div. Horrible.

There are many issues in using a non-button element:

1. The control likely isn’t going to be keyboard operable, which is the bare minimum of accessibility conformance.
2. To make <a> focusable, you need to give it a URL which produces this grape soup “a href=”#”.
3. Another bad side effect of using <a> for a button is even if you code the entire functionality from scratch, the control will still show up as a link if the user has enabled Windows High Contrast Mode.

Instead, use the button element, which has accessibility features baked in, such as activation on Spacebar / Enter, focusability and it shows up as a button in Windows High Contrast Mode (make sure you use border: transparent instead of border:none).

If you can’t use the button element, as a last resort, replicate it using the guide of ARIA Authoring Practices. But remember, do that if you absolutely have no other choice, because it’s kind of like having to use a newspaper as toilet paper.

Don’t: Toggle both aria-label and aria-pressed attributes

If you are not using a checkbox, then most developers utilize a toggle button with an aria-label as its accessible name. Which is fine, but toggling the values of both attributes is a bad practice.

Personally, I am always queasy when I am tasked to switch the values of the aria-label since I regard names as something semi-permanent, and, screen readers really do not like dynamic accessible names.

Whereas state attributes such as aria-pressed are meant to be dynamic, so toggling their values is not only expected, but very well supported by screen readers.

Changing both just spells chaos. Some screen readers will not announce the new name, or would announce the new name with the old state and vice versa.

Do: Choose a meaningful accessible name

Most password buttons are usually just a button with an icon. So choosing the right accessible name is vital so that screen readers can announce to the the user what the control is supposed to do.

You can’t go wrong with naming your buttons “Show Password” or “Toggle password visibility”, as long as you combine them with a state marker such as aria-pressed.

Don’t: Make the target area smaller than 44 x 44 pixels

You might be thinking “But Stefany, the WCAG Success Criterion 2.5.8 AA requires the target area or spacing to be at least 24 x 24 pixels”. True! But when it comes to target / control sizes, I tend to design them as big to 44 pixels as I can get away with, for the following reasons:

1. Even the abovementioned Success Criterion suggests making the target areas at least 44 x 44 pixels for “important links and controls”.
2. It is actually recommended in the WCAG to stick to a minimum size of 44 x 44 pixels, but since the Success Criterion for the recommendation is triple A, a lot of accessibility professionals completely ignore it, which is a mistake.
3. The WCAG makes it a point to underline that we should try to implement triple A Success Criteria as much as possible and making controls just a little bit bigger is easy.
4. One of the leaders in accessibility, Apple, also recommends 44 x 44 pixels of minimum target size*.
5. Larger target size controls are mainly there to help people with tremors activate controls, no matter if they are using their fingers or a mouse. But in addition, it helps people whenever there is shaking happening while they are using their phones, such as a bumpy bus ride, an earthquake or if you are at a concert.

If there is enough interest, I’d be happy to write an in-depth article on why I prefer the larger buttons and the benefits they have.

Don’t: Use a low contrast color icon

If you are using a graphic button, then you need to be careful that the icon doesn’t drown into the website’s design. A common practice is for those icons to be grey, which is fine, but the majority of websites have a white background, which makes most of those controls fail color contrast guidelines.

That doesn’t mean you should never use the color grey on a light background — just apply a darker shade so that the color contrast is 3:1.

Conclusion

No user interface will be anniversary accessible, no matter how much time and effort is spent, simply because we as humans are unique. By at least adhering to simple accessibility rules, we can ensure a large portion of the users will have good and accessible experience.

I see a lot of articles and components claiming to tell people how to code the “perfect” button, or link, which is impossible. But think of “show password” components like toilet paper — a one-ply toilet paper is preferable to none, but a person would very much prefer a two-ply.

Thank you for wanting to make the world more accessible by reading this article!

*Technically, the Apple Human Interface Guidelines recommend 44 x 44 points, not pixels, in order to accommodate their retina displays. However, the minimum of their definition of 1 point is 1 pixel.

Code

HTML

<section>
    <h1 class="heading" tabindex="-1">
        About Our Fencing Club
    </h1>

    <p>
        We are a community organization that brings together individuals with a passion for the sport of fencing.
        Members of the club have the opportunity to participate in fencing classes, workshops, and sparring sessions
        under the guidance of experienced coaches.
    </p>

    <p>
        The club provides a supportive and encouraging environment for fencers of all levels, from beginners to advanced
        athletes, to improve their skills, compete in tournaments, and enjoy the camaraderie of fellow fencers. 
    </p>
</section>

• Make sure the heading matches the title of the page, if possible. This way when focus lands on it, screen reader users can immediately figure out if they are at the right page.
• We are adding tabindex=”-1” which makes it possible to place a focus programmatically on a non-interactive element (with the JavaScript .focus() method you will see below).
• We are giving the heading a class name so we can fetch it and manipulate it with JavaScript.
• Alternatively, you can also traverse the DOM and fetch the first h1 on the page, if your pages are built with semantic principles in mind (also known as competently built), but I avoid this method because if the page has an additional h1 heading, it might spell chaos.
• Developers mistakenly think that section elements have a semantic meaning, but that is not true. If we give the section an accessible name, only then would it become a landmark. Since our page is simple, there is no need to pollute the screen reader landmarks list.

JavaScript code

Simplest

const firstHeading = document.querySelector(".heading");

document.addEventListener("DOMContentLoaded", () => firstHeading.focus());

• First we fetch the heading using its class name and add it in the constant firstHeading
• Then we try to figure out when the DOM content has loaded. Note that we are not using the load event, which is much slower and unnecessary in this case. Once the DOM is loaded, we swiftly move focus to the heading with the .focus() method
• Focus now moves to the first heading when page is loaded

Longer yet more robust code

You can remove the tabindex attribute of the heading once focus leaves the element. Occasionally, leaving tabindex=”-1” on static elements that no longer require focus can have side effects. It has happened to me that Internet Explorer would still place focus on static elements containing the negative tabindex; we can add a line to remove the now redundant attribute.

const firstHeading = document.querySelector(".heading");

document.addEventListener("DOMContentLoaded", () => firstHeading.focus());

// Removes tabindex=-1 from the heading due to potential bugs
firstHeading.addEventListener(
   "blur", () => firstHeading.removeAttribute("tabindex")
);

Use Cases

So you might be thinking — what would be the point of making headings focusable? Isn’t that against accessibility principles?

There are numerous examples when making headings focusable can be beneficial for the user:

Single Page Applications

Ever since smartphones became popular, website owners became obsessed with the ludicrous idea of making websites behave and look like mobile apps. Which meant disabling the ability of the browsers to refresh when the user navigates to a different page, so that the user experience feels “app-like”, as if the end user cares. But I digress.

Since browser refresh doesn’t occur in Single Page Applications (which, let’s face it, are most ReactJS websites), authors have to manage focus themselves. If focus management is left to the browser — which let’s face it, it often is, since web developers usually don’t bother learning accessibility — then different browsers would put the focus wherever they want, following loose guidelines such as the sequential focus navigation starting point. And you definitely don’t want that.

So a technique often used is to place the focus on the first, often h1, heading of the page.

When an element is destroyed after “closing it”

Occasionally, when an element is closed / destroyed, focus is lost. Sometimes the best place to move the focus is on another heading, if that is indeed the most logical place for the user.

For example, if you have a window with a close button that prompts the user to register for an account, and the user closes said window, then maybe the best place to place the focus would be the hero heading.

Modal dialog windows

The accessibility community is somewhat split on where to place focus when a modal window opens, since the website has to become inert when the modal is invoked. Some experts believe that the focus should go to the first heading, while some believe the window itself is a better focus target.

Skip to Main Content

While it is common practice to move the focus to the main element after “Skip to main content” links, sometimes it makes more sense to focus the h1 heading instead, for example, if you need to support older browsers, or when confronted with unexpected screen reader behavior (looking at you, TalkBack…).

Conclusion

Managing focus is crucial for accessibility and it is often quite difficult to do. Hopefully this article helped.

I know most of the tickets I have to write as an accessibility architect often include focus management.

Always make sure to test with different screen readers.

Photo by Grianghraf on Unsplash

Do: Make it keyboard accessible

I have seen a lot of cookie banners that can’t be reached by tabbing the page. That’s really bad.

However, then comes the question in what focus order the cookie banner should exist on the page — which is a whole other long discussion. For now, just focus on the banner to be tabbable and its buttons and links such as, “Learn More”, “Privacy Policy”, etc.

Do: Add a landmark with an accessible name

Developers tend to think landmarks are only useful to screen reader users which is not true. A browser plugin can extract landmarks and allow sighted users to skip section of the page easily. Especially if the website is cluttered with too many interactive elements, as most websites are.

I suggest you use the `region` landmark since it can be fitted anywhere inside the <body> tag and it was literally created to find what you are looking for.

WAI’s description of the `region` landmark explains it better than I can:

A region landmark is a perceivable section of the page containing content that is sufficiently important for users to be able to navigate to the section.

The accessible name could be as simple as “Cookie Banner” or “Accept or Reject Cookies” or similar. Resist the urge to name it: “A useless freaking banner”.

The end code should be something like this:

<!-- A cookie banner with a region landmark (2 ways)  --> 
<!-- Good --> 
<div role="region" aria-label="Cookie Banner">
  ...
</div>
<!-- section tags implicitly (automatically) have the role of "region" if you give them an accessible name —>
with either `aria-label` or `aria-labelledby`. 
<!-- Better -->
<section aria-label="Cookie Banner">
  ... 
</section>

<!-- Best -->
<section aria-labelledby="cookie_heading">
  <h2 id="cookie_heading">
    We use cookies on this site
  </h2>
  ... 
</section>

`section` tag has an implicit role of “region” if an accessible name is defined.

Whatever you do, do not add role=”banner” to your cookie banner! The ARIA role=”banner” and “a banner” are two completely different things! And yes, there is a very popular website right now whose cookie `div` has a role of “banner” for whatever reason.

Do: Use plain language

Plain language is very important and is often ignored; especially when it comes to compliance. It is vital for people with learning, cognitive, or neurological developmental disabilities. Not to mention people that pick-up English as their second or third language (like myself). Or folks who just don’t want to look up words when they want to do something as simple as order toilet paper online after a long day at work, or in the middle of their toilet paper emergency.

Language on the banner must be as simple as what the legal department of your company would allow. If you can use synonyms for complex words, that would be best. Note that I only mean the text displayed in the banner, not the pages linked within. While it is also encouraged to use plain language in the Privacy and/or Cookie Policy pages, I understand it’s not always possible since you need to remain compliant.

Do: Try to keep the interface as simple as possible

Remember that simplicity is the biggest ally of accessibility and overall, just good user experience (UX). The cookie banner is just a container for links and buttons. I have seen banners with dropdown buttons, tables, and other UI elements that don’t belong there.

Remember that most people will just dismiss the banner as quickly as possible, and nearly no one is going to read paragraph upon paragraph. Unless, they’re specifically looking for details about their user data, and that’s why we include Cookie / Privacy Policy links in the cookie banner.

Don’t: Make the cookie banner sticky on browser zoom

This is a sin of a lot of websites, since the banners are usually sticky (they follow you around as you scroll the page), when you zoom in the browser, they become giant and obstruct the view of the user.

However, you also need to make sure that the cookie banner scales up as the user zooms into the page, otherwise you will fail two WCAG Success Criteria, 1.4.4: Resize Text (Level AA) and 1.4.10:Reflow (Level AA)

Don’t: Use a third party cookie banner without performing manual accessibility testing

When I searched “Create a cookie banner”, all Google first page results were links to third party plugins, promising a “5 minute setup” and some other nonsense. But not a single plugin promised accessibility, at least from their landing pages.

The issue is that even if you find a plugin that promises to be accessible, or “WCAG compliant”, you need to perform your own accessibility audit. Companies lie about accessibility all the time. Ask for a demo of the code before purchasing and do a thorough testing.

I think when it comes to cookie banners, the best way is to code them yourself, or the development team of your company. I have never found an accessible cookie banner out of the box. Even if one exists, if your dev team doesn’t know anything about accessibility, they can mess up the setup so much that it becomes inaccessible once it goes live on your website.

Don’t: Make the cookie banner pop up, or a modal

Modals are windows that block user access outside their container. If used properly, modals can improve the user experience, but unless you have a good reason, do not make your cookie banner a modal window or a “pop up”.

Pop-ups, similar to those annoying newsletter subscriptions requests, are horrible for user experience. Imagine dismissing one and then suddenly another pops up!

Also if you are tempted to make the banner a modal, don’t do it. Remember, when a cookie banner is in the page, it must be keyboard accessible and to be one of the first things a user focuses on the page, unless there is a convenient link to it. So if it is a modal, when once the user tabs to it, they will be stuck and probably quite angry. Don’t do that to your users.

Don’t: Put the cookie banner as the last focusable item on your website

Especially if the cookie banner is sticky (follows you around), and a sighted keyboard user wants to dismiss it, they’d have to Tab through all of the buttons and links on the web page to find it and close it.

If you have no choice in the matter, assign the parent element a landmark (region is the best one) and/or add a skip link that shows up on focus right next to the Skip to Content link. I like this method because it doesn’t show the link unless you press Tab on page load, which means designers won’t be mad at you for “messing up” their Figma.
Code below:

<div class=”skips”> 
 <a href=”#”>Skip to main content</a>
 <a href=”#”>Skip to cookie banner</a>
</div>

— — — — — — — — — — — — — — — — — — — — — — — — —

Code

Photo by Adeolu Eletu on Unsplash

Does this situation seem familiar to you?

You are an accessibility expert sitting in a feature planning meeting, discussing how a closed captioning component must be made accessible to blind people when some ignorant coworker who outranks you, blurts out:

“There is no need to make the caption menu accessible to blind users because blind people can’t see the captions.”

When you try to politely explain why they are wrong, you get interrupted right away and dismissed. Or worse, they tell you they will discuss this “offline” which is the corporate version of ghosting.

So the next time this happens, share this article.

A lot of sighted people use screen readers

In fact, when WebAIM conducted a survey asking screen reader users what their disability was, 79.5% reported blindness. Bearing in mind that participants were able to choose more than one disability, that still leaves potentially 20.5% of users using screen readers without being blind.

And there are many reasons a sighted person might use a screen reader:

1. To avoid migraine attacks triggered by digital screens
2. Due to cognitive disabilities, such as folks with ADHD
3. Low vision users
4. Sensory overload, sometimes experienced by people with autism
5. Personal preference

Any one of those conditions could be combined with deafness, which would make captions and the ability to enable them with a screen reader crucial.

Blind people have families and friends with various disabilities

A blind parent might have a deaf child, and they will need to be able to enable closed captions on Paw Patrol. Another blind person who is hosting a Twilight marathon with their friends, one of whom is hard-of-hearing and another whose English is their second language, might need captions, so the host needs the ability to enable them on the TV.

You might be thinking, “Wouldn’t it be easier for their sighted friends to enable the captions instead?” No.

First of all, we all like being independent, and we don’t like bothering people. Second of all, have you ever tried to operate a TV that isn’t your own? It’s like a maze, with all the buttons and remotes. And third of all, what if you don’t speak the language the TV settings are on? The list goes on.

If we want screen readers to properly read the content, all parts of it must be accessible

If you have a video player that is coded accessibly with semantic HTML and ARIA, but the closed captions button is just a nameless `div`, it might at the very least confuse screen readers; at worst, it might be completely inaccessible using assistive technology. Just imagine a keyboard trap — or just a “clickable” screen reader announcement — can confuse the user and prevent them from operating the player at all.

Imagine buying a sweater only to find out that the neck is too small. Sure, it looked great in the store, but when you wanted to use it, it had a defect that made it unusable. Technically it is still a sweater, and people will wear it if they don’t have any other clothes, but it is a horrible product. Is that what you want your customers to think about your company?

Lawsuits, lawsuits, lawsuits

Every time you create an inaccessible product, you leave the door open to lawsuits. It’s like putting a bumper sticker on your car that says “I love speeding.” And a customer who is unable to play a movie, podcast, or even a commercial will be rightfully upset and can sue your company.

Conclusion

It is dangerous and inappropriate to make assumptions about your users without conducting user testing, or at least doing your own research. If there is no money for user testing, there are many nonprofit organizations that work with disabled people you could reach out to get more information, donate, or volunteer. The opportunities are endless.

This article was reviewed by Ariel Ferro, a programmer who happens to be blind.

Photo by Monica Flores on Unsplash

Warning: There is an auto-playing GIF without flashes further down the article.

Functionality of inert

The day we have all been waiting for is finally here. The difficulty of coding accessible modal windows went from “super super difficult” to “super difficult” — all thanks to the `inert` attribute.

The way it works is by disabling the keyboard and screen reader focus of an element and its children. Now, you might be thinking, “Duh Stefany, isn’t that what `aria-hidden`, and `tabindex=-1` and `display: none` is for?” Yes, but note how you described three different methods for hiding content using three different technologies? This is where the difficulty of managing focus comes from.

Each modal dialog must trigger the following:

1. All functionality behind the dialog must be disabled — such as buttons, links, and even static elements, such as plain text. Those must be disabled for as many assistive technologies as possible, such as screen readers, keyboards, voice recognition, everything.
2. Background is visible, but dimmed.
3. Focus is contained only within the dialog. Pressing the Tab key multiple times should make the focus move around inside the dialog, until it reaches the last interactive element and then starts again in a circle, much like a roundabout.

The focus in a modal dialog must be trapped, as if you are driving in a roundabout: you can only go outside of the dialog if you exit it, and you must drive around the roundabout until you need to exit. The inert attribute makes this very easy.

The code

When the user activates #dialogTrigger, and the dialog appears, we want to disable the background of the website and dim it while trapping the focus inside the dialog.

You might be thinking, “Stefany, it’s so easy, just add `display: none;` on the <main>”. There are two issues that prevent us from just slapping display: none; everywhere: animation and visibility.

Hiding elements with CSS display: none; will hide it from everyone — sighted users included. Hiding it from everyone makes for a bad user experience. Remember that we want to dim the website but keep it visible — we can’t do that with display: none.

This is where `inert` comes in. Just adding `inert` to the <main> tag will hide all its children for everyone but sighted users, which is what we need. Since it is a Boolean attribute, meaning it just returns “true” or “false,” we can throw it around like a football between the <main> tag and #modalDialog, depending on which element is supposed to be inactive.

GIF showing how the inert attribute is applied dynamically on the modal window and website content container (main & #modalDialog), depending on which one of them is active. The DOM is manipulated with JavaScript.

Browser support is awesome, except for Firefox

At this time of writing (January 2, 2022), `inert` is supported by all major browsers on desktop and mobile, except Firefox, but we can add a polyfill to remedy this situation. Before you take a breath to argue that polyfills slow down websites, make sure you measure exactly how slow it makes your application and then figure out whether there are other areas you can improve the performance. The most important thing I want to underline is that this attribute prevents so many developer mistakes and makes coding faster. Every time I start a new job as an accessibility engineer at a company, the number of bugs I encounter concerning focus in modal dialogs are usually in the hundreds, since it is very difficult to make them accessible.

Conclusion

You can use `inert` for other components too, such as hamburger menus, off-canvas navigation, or just a modal dropdown dialog. Anytime you need a piece of interface to be visible but inactive, just add inert to the parent element. It’s so simple, it’s kind of like the Better Than Bouillon of the Internet. I think the biggest asset of inert is its ability to be animateable — nowadays, everyone expects your interfaces to feel natural with transitions and whatnot, and the reason display: none; is rarely used is because you can’t animate it. Remember to always check whether the user has enabled animations on their operating system before animating, of course.

Inert makes writing JavaScript or React so simple and straightforward since we are using a browser’s built-in method. The less code you have to write, the lower the chances of introducing bugs.

Resources

• Code on Codepen
• Inert | The CSS Podcast
• MDN — inert
• ARIA Authoring Practices Guide (APG) — Modal

Photos by Lucas Miguel, and engin akyurt on Unsplash

Summary: The experience was mostly positive, the only issues being that the staff wasn’t properly trained to handle accessibility tests and there was a lack of directions.

As I finished my first accessibility test and rewarded myself with a bucket of graham crackers and an episode of Gossip Girl, I suddenly got an idea: what if I take the Web Accessibility Specialist (WAS) exam in the same testing window as the Certified Professional in Accessibility Core Competencies (CPACC)? Since I had just spent the past 2 months studying — and because a lot of the questions in the CPACC exam are likely in the WAS certification as well — I figured I would have higher chances of passing. And since I wouldn’t know for months whether I passed the CPACC, taking the WAS could act as a fallback or as insurance in case I failed the CPACC. Or, I could fail them both at the same time; that would be embarrassing for sure.

I scheduled my WAS exam for August 10, 2022, at the Tulsa Technology Center. I chose to take it at a testing center instead of taking the home proctored exam since the Kryterion requirements for a home exam have ridiculous rules.

Exam Day

Because I am a morning person, I scheduled my exam for 8:30 a.m. The nearest testing center was in Tulsa, which was about 20 minutes from my home.

The Tulsa Technology Center is part of the university, which made me feel like a muggle in Hogwarts, since I don’t have a college degree, but I sure hang out at universities a lot. The exam email didn’t specify where exactly in the building the test was going to take place, so I had to find it, which was confusing since no one there had ever heard of the WAS exam.

“Hello, where is the Web Accessibility Specialist exam taking place?” I asked security.

“The what?”

I repeated the question.

“I don’t know,” they said.

“Where do people usually take exams here?”

“In the university? Everywhere,” they responded.

I rephrased, even more frustrated now, “OK, where do people who don’t go to university take their exams?”

“Oh, over there,” and they pointed to an office.

Relieved that I wasn’t completely lost, I went to the office and the same conversation ensued with the staff there.

“Hello, is this the place where the Web Accessibility Specialist exam is taking place?” I asked.

“The what?”

I was getting more and more frustrated, was scared that I was lost, and I feared I would miss the exam. On top of that, if you don’t show up to your exam or fail to cancel within 4 business days of the test date, the IAAP will keep all the money, which is so unfair — especially to disabled people and those with chronic illness. Moreover, I really didn’t want to lose the $430 I had paid for it. I would rather spend my money on more useful things, like Tamagotchis.

So I repeated the question and started trembling.

“You might want to try the building next to us,” they replied.

Scared, I started to exit the office when I heard, “Wait!”

A woman suddenly opened a folder and asked,

“Is this a Kryterion exam?”

“Yes!” I said, full of hope.

“Oh, you should have said that. But we only conducted one Kryterion exam a few months ago for this dude. Sit down and wait.”

At least there was some progress. I also mentally thanked the “dude” who was here before me so they didn’t chase me out of the office.

I waited for about half an hour, and the staff had to make multiple calls and open many folders, but — finally — they figured it out.

“Okay Stefany, put all your stuff in the locker, including your watch. Show us 2 forms of ID and the confirmation email Kryterion sent you.”

As I obliged, I was escorted to the exam room. It was super tiny and contained a computer that looked like it was manufactured when I was born, and it also featured cameras on the ceiling. It kind of reminded me of an interrogation room.

“Tap the glass if you need help or need to go to the bathroom. You will be recorded, so don’t move around,” they said.

Taking the exam

The exam is usually 2 hours, but I was given 3, since English isn’t my first language; I thought this was great.

The first thing I noticed was that the monitor’s contrast was super high. I was barely able to distinguish input boxes, as the screen was super bright. The computer was very loud — it likely hadn’t been dusted since the 90s — and the peripherals were in the same bad condition.

Sometimes I had to lean in really close to the monitor because of the brightness issues, and I was afraid of telling the staff because I didn’t want them to tell me to go away or for them to think I was trying to cheat. I also thought that maybe the super bright monitor was there on purpose to make the exam more difficult.

Another obstacle was that since the WAS is targeted at developers, there were a lot of code questions, but the code wasn’t formatted, so I had to think really hard about the structure and, again, lean in close.

And of course the questions were vague: it was difficult to understand what the question was asking you to figure out, but I assume that’s on purpose.

The questions that gave me the most trouble were those asking you to choose the “best way” to code an accessible widget, which is subjective, given that accessibility is not a red and blue science: it’s relative.

The second toughest thing was asking the “A” levels of various WCAG Success Criteria.

I finished the exam and went home, and in about a month, I got the results showing that I had passed.

Overall, my experience was much better than the home proctored exam. There was less noise, and there was almost no chance of a power or Internet outage because it was taking place at a university campus. Likewise, there was no chance of various ghosts interfering.

Tips for taking the exam at a testing center in the United States

1. Visit the place the day before and find the office within the building where the exam is taking place to make sure that when you arrive, you won’t be lost like me.
2. Request earplugs if you are sensitive to noise.
3. Schedule the exam at the time of day you feel the most energized and razor sharp. I am a morning person, so I scheduled it early in the morning.
4. Take as few electronics as possible with you, since you will be asked to surrender them.
5. Bring 2 forms of identification and the confirmation email with the code. One of them must be a photo ID, such as a passport or a driver’s license. I only brought my state ID, but thankfully they accepted my debit card as a second form of identification; otherwise, if I had to go home, I would have lost 100% of my exam fees. You can email Kryterion to ask what other forms of ID are acceptable, but I assume a health insurance or passport card would have been accepted as well.

After 2 months of memorizing international and American accessibility laws, assistive technologies, and so on, the day came to take the Certified Professional in Accessibility Core Competencies (CPACC) exam, offered by the International Association of Accessibility Professionals (IAAP) and proctored by Kryterion. However, I didn’t expect the experience would be similar to getting a tooth pulled.

The home proctored exam rules and my preparation

A home proctored exam means that someone is watching you and recording you through your webcam constantly, but you can’t see them (so not much different than everyday life, but still frustrating). The night before my exam, I spent 2 hours removing and covering up all the monitors and TVs in my home office, as well as removing all the Sailor Moon figures from my desk. I was allowed only tissues, water and snacks.

So to take the exam at home with the proctoring company the IAAP has hired, you must obey their absurd rules for making your office “good enough” for them:

• You must remove non-essential computer stuff from your desk and are allowed only water, tissues (for crying during the exam, which will absolutely happen) and snacks.
• You must plug in an external microphone so that they can record sound too. I thought my webcam with a microphone would be enough, but after chatting with support, I plugged in my Yeti mic.
• No pens, paper, pencils or anything you can write with.
• You must cover all electronic devices in the room, especially if they have screens, like monitors or TVs.
• Remove all items from the walls in the part of the room where the computer is, even if it is behind you.
• You can’t take the exam on a Chromebook.
• No wristwatches of any kind, Google glasses, Star Trek badges, or headphones are allowed.

There were even more rules, but I am trying to keep my word count low. Basically, Kriterion and the IAAP treat every person taking their exams as a cheater. Feels great.

It took me 2 hours to cover and remove things from the walls and the desk, and I was super stressed the night before.

Then, when you actually take the exam, more ridiculous rules await you. During the exam, you are not allowed to do the following:

• Look around the room, or even turn your head away from the monitor
• Whisper or talk to yourself.
• Go to the bathroom without permission.

Additionally, the proctor is constantly watching you through your webcam, but you can’t see them — which is so creepy since you don’t know what they are doing while watching you.

Exam Day

I was nervous, which is normal, and didn’t sleep well the night before, so always take into account that you might not get enough rest before an exam. I signed up to take a morning exam, since that’s when I feel the most energized and productive.

So, I woke up, put on the outfit I picked from the day before, did my makeup, had a bowl of oatmeal — which is brain food — and then reviewed my index cards.

You are supposed to be at your computer 10 minutes before the exam starts, but I sat down 30 minutes before, since I didn’t want something unfortunate to happen. For example, if a Windows update starts, that would ruin everything. If you don’t show up for the exam, you must forfeit the fees.

Next, I logged into the Kryterion website, and I was given instructions to take 2 selfies via my webcam with good light, confirm my identity, and, lastly, to launch the software they made me install the night before that blocks you from using your computer, except when answering questions and allows the proctor to see everything happening on the screen.

The test started, and about 10 minutes in, my screen suddenly went blank, and I saw the proctor chatting with me on the computer, while watching me still through the camera:

“Hello, please show me your pencil and paper.”

“I don’t have a pencil and paper,” I said, confused, since the rules forbade their use.

“OK, you may bring pencil and paper to the desk, if you want,” they replied.

I was surprised since, again, those were forbidden! Then I suspected that the proctor was probably trying to make me do something illegal to make me fail my test, so I refused the pencil and paper, and the test was resumed. (After the exam ended, I realized I might have overreacted, but I didn’t want to take any chances.)

Suddenly, I realized I had made a horrible mistake. I didn’t ask my husband to take the day off! We both work from home, but he works as an insurance adjuster, so he speaks to clients all day. I could hear him perfectly through the wall separating us. Of course, that wouldn’t have been an issue if we were allowed to wear noise canceling headphones.

I tried to ignore my husband, but it was impossible, especially since the questions were mostly “What is the best way to do X?” which required a lot of deep thinking. However, I could hear him trying to help someone file an insurance claim. I started crying, thinking I would fail, which surprisingly didn’t bother the proctors at all. So whispering and looking around are big no-nos, but crying is okay. Makes perfect sense.

Another thing that was super stressful was that the screen froze a few times, saying it had trouble connecting to the Internet. I was afraid of missing my exam potentially due to an electricity and/or power outage. I had previously asked the IAAP folks what would happen to my exam, and they assured me I’d be able to reschedule. Thankfully, I scheduled my exam on the week of the 6 weeks window, but if I had scheduled it for the final week, then I’d have to wait a month to take it again.

There were also other sounds, like a lawn mower, delivery people knocking at the door, and kids yelling outside. Just some of the many reasons why you shouldn’t take exams at home.

I didn’t experience any other problems, other than having to go to the bathroom but being too afraid to ask for permission; the exam finished, and after about 45 days, I got the certificate. The test is usually 2 hours, but I was given 3 hours, since English is my second language. I finished it in 70 minutes.

Tips for a better experience taking the home proctored exam

Although I recommend taking the exam at a testing center, doing so isn’t always possible, since you might live in a rural area, need assistive technology, or like me, can’t drive. So here are some tips to take the experience from “super awful” to just “awful”:

1. Schedule the exam at the beginning of the exam period, just in case you get sick or the computer/Internet malfunctions. That way, you’d have time to reschedule it as soon as possible. For example, the exam period for me was July 20 — August 24, 2022, and I scheduled my CPACC on July 21, 2022, and my Web Accessibility Specialist exam on August 10, 2022.
2. If you live with a roommate and/or a partner, ask them to take the day off from work, or to leave the house for the duration of the exam, which is usually 2 or 3 hours.
3. Prepare your home office and desk for the exam on the day before.
4. Schedule the exam at the time of day you feel the most energized and razor sharp. I am a morning person, so I scheduled it early in the morning.
5. Be at the computer ready to press the “Start Exam” button at least 30 minutes before your official start time in case the PC needs to update or another surprising thing happens.
6. Delete the tracking software Kryterion forced you to install immediately after the exam ends.
7. Since the proctors can ask you to show them your room with the webcam at any time during the exam, make sure you remove all your Blackpink dolls too.