La accesibilidad web tiene mala fama de tema aburrido y caro, y suele quedarse en la lista de «cuando tengamos tiempo». Merece la pena replantearlo por tres motivos muy concretos: afecta a mucha más gente de la que parece, buena parte de lo que arreglas mejora la web para todos, y desde hace unos años hay obligaciones legales que alcanzan a bastantes empresas privadas en España.
La buena noticia: la mayor parte de los problemas de accesibilidad de un WordPress normal son cuatro o cinco cosas repetidas, se detectan en una tarde y se arreglan sin rehacer nada.
Antes de empezar: qué detecta una máquina y qué no
Esto marca todo el enfoque, así que va primero.
Las herramientas automáticas —y la IA entre ellas— detectan de forma fiable en torno a un tercio de los problemas reales de accesibilidad. Son excelentes en lo medible: contraste de color insuficiente, una imagen sin atributo alt, un campo de formulario sin etiqueta, una jerarquía de encabezados rota.
Lo que no pueden juzgar es el sentido. Una imagen puede tener un alt que diga «imagen1.jpg» y la máquina lo dará por correcto porque el atributo existe. Un enlace que dice «haz clic aquí» pasa cualquier validador y es inútil para alguien que navega saltando de enlace en enlace.
Conclusión práctica: usa las herramientas para el barrido inicial y reserva media hora para probar a mano. Las dos partes juntas cubren la gran mayoría; ninguna de las dos sola basta.
Paso 1: barrido automático
Empieza con dos extensiones de navegador gratuitas: WAVE y axe DevTools. Las dos analizan la página abierta y señalan los problemas sobre el propio diseño.
Pásalas por cuatro páginas representativas: la portada, una entrada del blog, una página con formulario y —si vendes— una ficha de producto. No hace falta más para el diagnóstico inicial: los problemas de un WordPress son casi siempre del tema y de las plantillas, así que se repiten.
Apunta lo que salga. Verás que se agrupa en muy pocas categorías.
Paso 2: contraste de color
Es el problema número uno, con diferencia, y el más fácil de arreglar.
La norma pide una relación de contraste de al menos 4,5:1 entre texto y fondo para texto normal, y 3:1 para texto grande. En la práctica, los sospechosos habituales son siempre los mismos: el texto gris claro sobre blanco que queda tan elegante, los botones de color de marca con texto blanco encima, el texto sobre una imagen de cabecera y los enlaces del pie de página.
Aquí la IA ayuda de una forma muy concreta: dale tu paleta de marca y pídele combinaciones válidas.
«Mi paleta de marca es: [lista de colores en hexadecimal]. Calcula la relación de contraste de cada combinación de texto sobre fondo y dime cuáles cumplen WCAG AA (4,5:1 para texto normal). Para las que no cumplan, propón el ajuste mínimo del color de texto que sí cumpla manteniendo el tono lo más parecido posible al original.»
Ese «ajuste mínimo manteniendo el tono» es la clave para que el diseñador no se eche las manos a la cabeza: no se trata de cambiar la marca, sino de oscurecer un gris lo justo.
Paso 3: textos alternativos que sirvan
The alt de una imagen es lo que oye alguien que usa un lector de pantalla. También es lo que Google usa para entender la imagen, así que esto es accesibilidad y SEO a la vez.
Tres reglas que resuelven el noventa por ciento de los casos:
- Describe la función, no la imagen. If the photo illustrates a step in a tutorial, the
altshould say what is seen in that step, not "screenshot". - If the image is decorative, leave the
altempty. Truly empty (alt=""), not absent. This way the screen reader skips it instead of reading the file name. - If the image is a link or a button, the
altdescribes the destination, not the drawing. A shopping cart icon that leads to the cart is "View cart", not "cart icon".
To review the current status, in Media > Library you can see the alternative text field. If you have hundreds of images, prioritize: those on the most visited pages and those that are links.
AI can propose alternative texts from images, and it does so reasonably well. But review them: it describes what it sees, without knowing why the image is placed on your page, and that difference is precisely what matters.
Step 4: keyboard navigation
No tool does this test for you, and it's the one that uncovers the most problems. It takes five minutes.
Open your website, leave the mouse still, and navigate it only with the tab key:
- Do you always see where you are? There must be a visible indicator on the focused element. Many themes remove it for aesthetics with a
outline: none, and that leaves those who navigate this way blind. - Does the order make sense? It must follow the visual order. If it jumps from the menu to the footer and back to the middle, there's a structure problem.
- Can you open the dropdown menu? Menus that only respond to mouse hover are inaccessible by keyboard.
- Can you close pop-up windows? Try with Escape. A cookie notice or a subscription window that cannot be closed with the keyboard blocks the entire website.
- Do you get stuck somewhere? An embedded player or a map that captures focus and doesn't release it is a trap.
Point 4 deserves special attention because it affects almost all websites: between the cookie notice, some email capture window, and some chat, there are quite a few candidates to block keyboard navigation.
Step 5: forms
Forms concentrate a lot of problems because they are the most interactive part.
Check that each field has a truly associated label —not just example text inside the field, which disappears when typing—, that error messages explain what to correct instead of saying "error", that the error is also announced with text and not just by painting the border red, and that mandatory fields are indicated with more than a colored asterisk.
If you use a forms plugin, much of this comes resolved by default. If the form is from the theme or handmade, review it entirely. Our guide on contact forms in WordPress reviews the most common options.
Step 6: heading structure
Many people use headings for their font size: "I want this text big, I'll put H2". For someone navigating with a screen reader, headings are the document's index and jumping from one to another is the main way to move.
The rules: a single H1 per page, which is the title; not skipping levels (from H2 a H4 directly, no); and that the heading text describes the section.
To review it quickly, the WAVE extension has an outline view that shows you the hierarchy at a glance. You can also paste the page's HTML into an AI and ask it for the heading tree with level breaks marked.
About automatic "accessibility overlays"
It deserves a warning, because they are advertised a lot.
They are plugins or scripts that promise to make your website accessible and comply with regulations by adding a line of code and a floating button with contrast and font size options.
It's worth knowing that these solutions have received serious criticism from disability user associations and accessibility specialists, and have been subject to lawsuits in several countries precisely for not solving what they promise. In many cases, they add a layer that interferes with the screen readers that the person already has configured.
There's no shortcut: accessibility is fixed in the HTML and CSS of the website, not with a layer on top. If you're going to invest money, invest it in correcting the theme, not in covering up the problem.
Frequently Asked Questions
Am I legally obliged?
In Spain, the public sector has been obliged for years. For private companies, Law 11/2023 transposes the European Accessibility Directive and extends obligations to certain digital services —e-commerce, banking, transport, among others— with application from June 2025, with exceptions for micro-enterprises. If your website sells or provides one of the covered services, it is advisable to consult an advisor, because the specific scope depends on your activity and size.
How long does it take to make it decent?
An audit like this, an afternoon. Correcting what's detected, between a few hours and a few days depending on how much the theme has been touched. The bulk is usually contrast and alternative texts, which are a lot of mechanical work but no technical difficulty.
Does it improve SEO?
Not directly, but many of the corrections coincide with good practices that do count: descriptive alternative texts, consistent heading hierarchy, links with meaningful text, and semantic HTML. It's one of those cases where fixing one thing improves the other by rebound.
Can I ask AI to correct the code directly?
For limited changes —add a aria-label, correcting a heading hierarchy, adjusting a color— works well. To rewrite a theme template, no: it doesn't have the context of your website and will break something. And if you touch theme files, always do it in a child theme and with backup.
To finish
Accessibility has been sold for years as a big and expensive project, and for a complex website it can be. For a normal WordPress, no: it's contrast, alternative texts, keyboard, forms, and headings. Five categories, an afternoon of review, and a while of corrections.
AI is a good co-pilot for the calculable parts and for generating drafts, and it's not useful for the most revealing test, which is navigating your own website with the tab key. Do that one yourself: it's five minutes and it's the most revealing of all.
If you like this type of practical reviews, in our free tools library you have utilities that work entirely in your browser, without uploading anything to any server.
