Accessibility and Character Count Design - Optimal Length for Alt Text and ARIA Labels
In web accessibility implementation, character count design is an often-overlooked element. If alt text is too long, screen reader users drown in a flood of information; if too short, the meaning of the image fails to come through. The same applies to ARIA labels and live region text - designing the right character count is the key to an accessible experience. This article explains the optimal character counts and implementation patterns for each element, grounded in WCAG guideline requirements.
Alt Text Character Count Design - The 125-Character Threshold and Its Rationale
The widely known recommendation for alt text is "125 characters or fewer." This number is not explicitly stated in the WCAG specification but derives from the behavior of major screen readers. JAWS (Job Access With Speech) may split alt text into segments when it exceeds approximately 125 characters. While NVDA and VoiceOver do not exhibit clear splitting behavior, lengthy alt text increases cognitive load for users, so brevity is recommended.
However, 125 characters is merely a guideline, and the optimal character count varies significantly depending on the type of image. The table below summarizes recommended alt text character counts by image type.
| Image Type | Recommended Length | Writing Tips | Example |
|---|---|---|---|
| Decorative image | 0 characters (empty alt) | Set alt="" so screen readers ignore it | alt="" |
| Icon / Button | 5-15 characters | Convey the function or action concisely | "Search", "Open menu" |
| Photo / Illustration | 30-80 characters | Describe the content and its contextual role | "Five team members discussing around a whiteboard in a meeting room" |
| Graph / Chart | 50-125 characters | Summarize data trends or conclusions | "Monthly sales trend for 2024. Peak in April with 30% year-over-year increase" |
| Infographic | 125 chars + longdesc | Put a summary in alt; provide details separately in text | Summary in alt, detailed description in the body text |
| Logo | 5-20 characters | State the organization name. The word "logo" is unnecessary | "Character Counter" |
| Image inside a link | 10-40 characters | Describe the link destination (not the image appearance) | "Download product catalog" |
| Formula / Code | Read-aloud text of the formula | Provide alternative text via MathML or aria-label | "E equals m c squared" |
A common implementation mistake is setting non-empty alt text on decorative images. Writing "decoration" or "image" for background patterns or divider images causes screen readers to announce meaningless information, degrading the user experience. Always set alt="" for decorative images, and ideally implement them with CSS background-image to remove them from the DOM entirely.
Writing Alt Text - The Context-Dependent Principle
The optimal alt text for the same image changes depending on the context in which it appears. This is because WCAG 2.2 Success Criterion 1.1.1 (Non-text Content) requires alternative text that "serves an equivalent purpose." For example, a photo of a dog in a "Pet Health Management" article requires different information than the same photo in a "Photography Techniques" article.
In the former case, you should include health information such as "A Golden Retriever standing on a scale. Ideal weight is 25-34 kg," while in the latter, you should focus on photographic technique: "Silhouette of a Golden Retriever shot in backlight. Background blurred at f/2.8 aperture." The character count naturally differs, but what matters is selecting information appropriate to the context.
As with error message design, writing alt text with an awareness of "what the user should do next" is effective. For product images on e-commerce sites, including information needed for purchase decisions such as color and size provides an equivalent shopping experience for users who cannot rely on vision.
ARIA Label Character Count Design
ARIA (Accessible Rich Internet Applications) attributes provide information to screen readers that HTML semantics alone cannot convey. Among them, aria-label and aria-labelledby are the most frequently used attributes, yet there are few clear guidelines for their character count design, leaving much to developer judgment.
| ARIA Attribute | Recommended Length | Purpose | Notes |
|---|---|---|---|
| aria-label | 5-40 characters | Directly specify the element's name | Prefer aria-labelledby when visible text exists |
| aria-labelledby | Depends on referenced element | Reference another element's text as the name | Multiple IDs can be specified separated by spaces |
| aria-describedby | 20-100 characters | Provide supplementary description | Read as a description, not a name |
| aria-roledescription | 5-20 characters | Custom description of a role | Use cautiously as it overrides the standard role description |
| aria-live region text | 10-60 characters | Announce dynamically changing content | Frequent updates can interrupt user actions |
When aria-label exceeds 40 characters, cognitive load increases for screen reader users. Setting aria-label="Main navigation" on a navigation landmark is fine, but when complex descriptions are needed, referencing a separate element with aria-describedby is more appropriate.
A mismatch between aria-label and visible text causes serious problems for voice control users. For example, if a button's visible text is "Submit" but aria-label="Submit form data" is set, saying "Click Submit" via voice control may fail to recognize the button. WCAG 2.2 Success Criterion 2.5.3 (Label in Name) requires that the accessible name include the visible text.
Screen Reader Speech Rate and Character Count
Screen reader users typically set the speech rate to 1.5-3 times the standard speed. Some experienced users go above 5x speed. In this high-speed reading environment, text length directly impacts the experience.
At standard speed (approximately 150 words/minute, or about 300 characters/minute for Japanese), reading 125 characters of alt text takes about 25 seconds. Even at 3x speed, it takes about 8 seconds. On a gallery page with 10 images, each with 125-character alt text, a screen reader user would spend over 80 seconds just passing through the gallery.
To mitigate this issue, the following strategies are effective for galleries and carousels:
- Keep each image's alt text to 30-50 characters and provide details on individual pages
- Add a label like
aria-label="Product image gallery (12 images)"to the entire gallery so users can skip it - Group with
role="group"to enable skipping via landmark navigation - Provide a "View all images" link leading to a list page with detailed descriptions
Form Accessibility and Character Count
Form element accessibility consists of four layers: labels, placeholders, error messages, and help text. The character count design of each layer determines the form's usability.
| Element | Recommended Length | Role | Implementation Notes |
|---|---|---|---|
| label element | 5-20 characters | Name of the input field | Always associate with the for attribute |
| placeholder | 10-30 characters | Show input examples | Do not use as a label substitute; it disappears on input |
| aria-describedby (help) | 20-60 characters | Explain input format or constraints | Read aloud on focus |
| Error message | 15-50 characters | Describe the error and how to fix it | Notify dynamically with aria-live="polite" |
| Submit button | 3-10 characters | Clearly state the action | Be specific: "Place order" rather than "Submit" |
The anti-pattern of using placeholders as label substitutes is particularly problematic from an accessibility standpoint. Placeholder text disappears once the user starts typing, so users may forget the field's purpose mid-input. Additionally, the default placeholder color in most browsers has an insufficient contrast ratio (about 2.5:1), failing to meet the WCAG minimum of 4.5:1. Like naming convention character count design, form labels should be concise yet clear.
Live Region Character Count Control
Live regions (aria-live) notify screen readers of dynamic page changes. They are used to convey visually changing content in real time, such as incoming chat messages, form validation results, and countdown timer updates.
The most important aspect of live region character count design is balancing update frequency with character count. As discussed in chatbot message design, when large amounts of text flow in a short time, screen reader users cannot process the information.
| Update Frequency | Recommended Length | aria-live Value | Examples |
|---|---|---|---|
| Real-time (under 1 second) | 5-15 characters | off (do not announce) | Timer, stock ticker |
| High frequency (1-5 seconds) | 10-30 characters | polite | Search result count, character counter |
| Medium frequency (5-30 seconds) | 20-60 characters | polite | Chat messages, notifications |
| Low frequency (30+ seconds) | 30-100 characters | polite | Form submission results, status updates |
| Urgent (immediate notification needed) | 10-40 characters | assertive | Error alerts, session expiration warnings |
aria-live="assertive" interrupts the current reading to announce immediately, so it should be limited to truly urgent situations. Using assertive for form validation errors would interrupt the reading every time the user types, making interaction difficult. Use polite for validation errors to notify after the user's current action is complete.
WCAG 2.2 Success Criteria and Character Count
WCAG 2.2 has no success criteria that directly regulate character count, but several criteria indirectly affect character count design.
| Success Criterion | Level | Impact on Character Count |
|---|---|---|
| 1.1.1 Non-text Content | A | Mandates providing alt text. Requires deciding between short and long descriptions |
| 1.3.1 Info and Relationships | A | Associating labels with input fields. Requires clear labels |
| 2.4.4 Link Purpose | A | Link text alone must convey the destination |
| 2.4.6 Headings and Labels | AA | Headings and labels must describe content. Requires concise yet specific character count design |
| 2.5.3 Label in Name | A | aria-label must include visible text. Requires character count consistency |
| 3.3.2 Labels or Instructions | A | Provide labels or instructions for input fields |
| 4.1.2 Name, Role, Value | A | Provide accessible names for custom components |
Success Criterion 2.4.4 (Link Purpose) shares a similar philosophy with OGP text optimization. Vague link text like "click here" or "details" prevents screen reader users from determining the destination when navigating a list of links. Descriptive text of about 15-40 characters, such as "Read the official WCAG 2.2 documentation," is recommended so the purpose is clear from the link text alone.
Accessibility and Character Count in Multilingual Sites
On multilingual sites, the same content can vary significantly in character count across languages. Translating English alt text to Japanese shrinks the character count by about 60-70%, while translating to German can expand it by about 130%. This variation across languages is covered in detail in multilingual text length design.
From an accessibility perspective, the most critical concern is missing translations for aria-label. It is not uncommon for visible HTML text to be translated while text referenced by aria-label or aria-describedby remains in the original language. When using an i18n framework, remember to include ARIA attribute text in the translation scope.
Proper use of the lang attribute is also important. When text in a language different from the page's overall language is included, setting the lang attribute on that element allows the screen reader to switch to the correct speech engine. For example, an English quote within a Japanese page should use <blockquote lang="en">.
Implementation Checklist - Quality Management for Accessibility Character Counts
To continuously manage the quality of accessibility character count design, we recommend incorporating the following checklist into your development process.
- Alt text: Are decorative images set to
alt=""? Do informational images have context-appropriate descriptions of 30-125 characters? - aria-label: Does it conflict with visible text? Is it within 40 characters?
- Form labels: Is every input field associated with a
labelelement? Are placeholders being used as label substitutes? - Link text: Are there links with only "click here" or "details"? Can the purpose be understood from the link text alone?
- Live regions: Is the character count appropriate for the update frequency? Is the use of
assertivetruly necessary? - Heading structure: Do headings accurately reflect the content? Can the page structure be understood by scanning headings alone?
- Error messages: Can the error content and fix be conveyed within 50 characters? Is it announced via
aria-live?
Automated testing tools (axe, Lighthouse, WAVE, etc.) can detect structural issues, but human review is essential for evaluating alt text quality and ARIA label appropriateness. Incorporating accessibility reviews into your development team's process and regularly conducting real-device testing with screen readers is the surest path to a truly accessible site.
You can also find related books on web accessibility on Amazon. Systematically learning WCAG success criteria will dramatically improve your judgment in character count design.