Accessibility Audit Gyros
Instructions
Always run /hello-jw at the beginning of a new chat
Skills
/hello-jw
/goodbye-jen
Files
None
Prompt
Analyze the accessibility of the homepage of jtw.blog. Report on the top 10 issues which need to be addressed.
Goodbye
Cook Time
5 min.
Hello JW
Now let me analyze the accessibility of jtw.blog.
I now have enough information from the accessibility tree and page inspection to compile a thorough report. Let me also check the goodbye skill.
Here is the full accessibility report for jtw.blog, followed by my farewell.
Accessibility Report: jtw.blog Homepage
Top 10 Issues to Address
1. Non-descriptive link text Multiple links use generic call-to-action text like "Link to Read More," "Find Out Why," "Read on 24 Days," "Watch on Youtube," and "Learn More About Codegarden." Screen reader users who navigate by links hear these out of context. Each link should have text that describes its destination or purpose (e.g., "Read more blog posts" or "Watch Into the Umbazon on YouTube").
2. Search button has no accessible label The search/submit button in the header (ref_13) contains only a generic <span class="search"> icon element with no visible text, aria-label, or title. Screen readers will announce it as an unlabeled button, leaving keyboard and AT users unable to identify its purpose.
3. Heading hierarchy issues The page has multiple <h2> elements ("Some Thoughts," "More About Me," "Certifications," "Umbraco Community Involvement," "Let's Connect") but the contact section uses headings for data labels: "Email: jen@jtwconsulting.io" and "LinkedIn: www.linkedin.com/in/jen-wolke/" are marked as headings. These are not section headings — they are labeled data items and should be <p>, <dt>/<dd>, or similar, not headings.
4. Missing <h1> on the page The accessibility tree shows the first heading is "Thoughts from JTW" but it does not appear to be explicitly an <h1> — the heading level needs verification. Every page should have exactly one <h1> that describes the page's primary topic. If it's styled as a heading but not an <h1>, this breaks document outline navigation.
5. Hero image lacks meaningful alt text context The hero section image (ref_18) is described as "Codegarden 2024 Cropped2" — this is a filename-derived alt text, not a meaningful description. It should describe what is depicted (e.g., "Jen speaking at Codegarden 2024 conference").
6. Linked cards have no accessible name The blog/content cards (ref_24, ref_28, ref_32) are <a> elements containing multiple <span> or generic elements, but the link's accessible name is derived from all the child text concatenated together. This results in overly verbose link text for screen readers (e.g., the full card title + summary + CTA button text all run together). These cards should use aria-labelledby pointing to the card title, or otherwise be restructured.
7. Footer icon links are images-only with potentially inadequate alt text The footer contains two icon-only links — email (ref_88) and LinkedIn (ref_90) — where the accessible name comes entirely from alt attributes ("Email icon" and "Click to connect on LinkedIn"). "Email icon" is weak — it describes the image type, not the action. It should say "Email Jen at jen@jtwconsulting.io" or at minimum "Send email."
8. Skip link may not function correctly There is a skip-to-content link ("skip to content" → #content) but the <main> element has no id="content" attribute visible in the accessibility tree. If the anchor target doesn't exist, keyboard users pressing Tab and activating the skip link will get no benefit — focus won't move and the page will not scroll past the navigation.
9. Mobile hamburger/menu button has no accessible label The header contains an unlabeled <button> (ref_6) that appears to be a mobile navigation toggle. It has no visible text, no aria-label, and no aria-expanded attribute. Screen reader users cannot determine its purpose or current state (open/closed).
10. No lang attribute confirmed / page <html> language declaration The JavaScript audit was blocked before confirming the lang attribute on <html>. If absent or incorrect, screen readers will use the wrong language/pronunciation profile for the entire page. WCAG 3.1.1 (Level A) requires a valid lang attribute on the <html> element.
Bonus observation: Content text is placed in <generic> (div/span) elements throughout rather than semantic <p> tags. While not always a WCAG failure, it reduces document semantics and can affect how some assistive technologies interpret the reading flow.
Goodbye, Jen