90 skills · sorted by relevance
Review interface copy for assumptions about disability, gender, or culture. Suggest neutral wording, clearer instructions, and constructive error messages that guide people through problems without blaming them or relying on culturally specific expressions.
Review web page headings for skipped levels and unclear hierarchy. Identify specific elements to adjust, explain how heading structure supports screen reader navigation, and describe how to verify the revised page with accessibility tools.
Find links that use identical text but lead to different URLs. Review the rendered page and suggest distinct labels or consistent destinations so readers, including people using screen readers, can understand where each link goes.
Review iframe and frame titles so screen reader users can identify embedded content before entering it. Find missing or empty title attributes, add meaningful descriptions, and verify the changes with browser accessibility tools or assistive technology.
Review decorative images and icons to prevent unnecessary screen reader announcements. Check empty alt text, aria-hidden, and relevant keyboard behavior, then suggest fixes for concrete accessibility issues without flagging decorative assets solely because they exist.
Find empty headings or headings containing only whitespace in rendered web pages. Guide fixes by adding descriptive text or removing unnecessary heading tags, helping screen reader users navigate a meaningful document structure.
Review HTML lists of terms and descriptions, finding dt and dd elements used without a containing dl. Help correct the structure so assistive technologies can associate each term with its description, and explain how to verify the fix.
Review GIFs, videos, and CSS animations for rapid flashing that may trigger seizures in photosensitive users. Check flash frequency and screen area, then suggest removing or slowing effects or replacing them with fades or static content.
Find empty links, unlabeled icon links, and broken destinations. Add descriptive text or labels that screen readers can announce, and fix or remove broken links so users can understand where each link leads.
Review keyboard focus, the element currently selected for interaction, to check that Tab navigation follows the page’s visual order. Identify HTML ordering issues and verify focus stays within dialogs and returns to their triggers.
Check HTML definition lists, which pair terms with descriptions, for structural problems. Identify invalid child elements and unclear relationships, suggest markup fixes, and explain how to verify that screen readers group the information correctly.
Review where keyboard focus, the current target for keyboard input, moves when dialogs open, views change, or content updates. Identify misplaced or lost focus and propose changes that help keyboard and screen reader users continue navigating.
Review links, buttons, and form fields for duplicate HTML IDs. Identify affected controls, suggest unique IDs, and explain how to verify keyboard navigation, focus movement, and screen reader behavior after the fix.
Review rendered HTML for duplicate IDs used by ARIA attributes, which connect elements to labels and descriptions for assistive technology. Identify ambiguous references, correct IDs and their links, and explain how to verify the changes.
Review buttons for missing or unclear names, including controls that contain only icons. Add text or labels that explain each action to screen reader users, and replace buttons used for page navigation with links.
Review rendered HTML for links, buttons, or inputs inside role="text" containers. Identify controls hidden from screen readers, suggest markup changes, and explain how to check keyboard access and screen reader output after fixing them.
Inspect hidden page regions for links, buttons, or inputs that still receive keyboard focus. Identify elements that screen readers cannot announce, suggest focus handling changes, and explain how to verify the resulting keyboard behavior.
Check whether aria-hidden on the document body hides an entire page from screen readers, tools that read content aloud. Identify problematic states and suggest limiting hiding to specific background containers.
Review tooltips so their extra information is available to screen reader users. Check accessible names, meaning labels available to assistive technology, and links to the elements that trigger them, then suggest fixes and verification steps.
Check checkboxes, radio buttons, and switches for descriptive names that screen readers can announce. Identify missing or unclear labels, suggest appropriate HTML or ARIA labeling, and explain how to verify the changes with accessibility tools.
Review HTML for deprecated ARIA roles, which describe elements to assistive technology, and abstract roles that should not appear in markup. Suggest recommended replacements or native HTML elements and explain potential browser and screen reader compatibility issues.
Review dynamic page updates so screen reader users hear status changes without moving focus. Check ARIA live regions, areas that announce updates, choose suitable announcement urgency, and identify markup or interaction issues to verify with accessibility tools.
Check whether ARIA attributes, which describe interface elements to assistive technology, are supported by each element’s role. Review rendered HTML and interactive states, identify invalid combinations, and suggest removals or corrections to support accurate screen reader interpretation.
Review progress bars to ensure screen reader users can tell which task they represent. Add descriptive accessible names, check progress semantics, and verify value attributes when the current progress is known.