[Bug]: Screen Reader Inaccessibility (Sighted Amateur Analysis)

[arazni]

Blazorise Version

Same as site's documentation

What Blazorise provider are you running on?

None

Link to minimal reproduction or a simple code snippet

Visit your documentation pages for components, e.g.: https://blazorise.com/docs/components/accordion

Steps to reproduce

I used NonVisual Desktop Access (NVDA) Version 2024.1.

I change the setting to use a visual sidebar so I can read what's being said instead of be spoken to. (The rapid robot speech is very overwhelming if you're not used to it).

I run the application and use some of the shortcuts to navigate, and it takes some practice to understand the different "modes" it uses. Some ones I use most:

• h: Scan to next header
• 3: Scan to next h3
• Down/Up keys: Read next/previous line
• Tab: Go to next input/interactable
• Shift + Shortcut Key: Scan in reverse direction
• Insert + B: Read modal/dialogue/popup

I ran it against your documentation component pages to manually test.

What is expected?

All inputs should be clear and accessible when tab-navigating. All labels should be clearly associated with their fields, such that tabbing into a field should have the screen reader read the label to you as part of recognizing the component.

What is actually happening?

Components are presented in alphabetical order. Larger headings are used for worse components.

Accordion (Good)

• Reads the text, says "heading level 5 button expanded/collapsed"
• Collapsed text is skipped over during reading, but read while expanded.

Addon (Pitfall)

• Placeholder text is not explained to be a placeholder, but reads as "{Placeholder} edit blank", which is appropriate when the placeholder text is "username" but may not be appropriate when the placeholder text is an example input.
• Start and end labels are read when scanning the page, but not when tabbing into the field, which may be confusing if the start/end label intends to actually label the field.
• The Dropdown example doesn't seem to work on the documentation site, so I can't test it.

Alert (Good?)

• Text and interactables within alerts seem to behave appropriately.
• It will seem like normal text unless the text itself explains that it's a warning. (Color won't help.)

Badge (Good?)

• These are just read as text with no additional dressing to indicate that they're badges.
• This may be appropriate, I don't know.

Bar (Pitfalls)

• BarDropdownToggle is read as a button, but not one that lets the user know whether it's expanded or collapsed.
• BarToggler cannot be tab navigated.
  • Demo for inline made it disappear completely, which was confusing
• Other components within the Bar seem to work as expected for a navigation link area.

Breadcrumb (Mostly good)

• Navigable and usable
• Manual mode's behavior is read out weirdly, for example: "link Home" "/" "link Library" "current page /" "Data"
• Unsure if I can fully test Auto mode's behavior, but it doesn't include the "current page /"

Button (Mostly good)

• Spinning loading icon is not discoverable to the screen reader
• Everything else seems as expected

Card (n/a)

• Card demos on documentation page may benefit from being h4s instead, to make heading-based screen-reader page scanning easier.

Carousel (Pitfall)

• Previous and Next graphic buttons are not discoverable by tabbing.
• Can be used by scanning the page outside of tab-based navigation.
• Text property is correctly read by the screen-reader, should likely have [EditorRequired] attribute if it's not already.

Check (Good)

• Always recognized as a checkbox, tabs work, and checked vs. not checked is read correctly

Close button (Good)

• Always read as "Close button" and tabs work

Color Edit (Good!)

• Surprisingly good, every component and selection including the color grid has its values recognized correctly and can be edited through keyboard
• Only the eyedropper is hard to use since it requires a mouse, but I'm not sure how applicable that is
• The color edit itself reads "clickable 100% red 0% green 0% blue", which is usable although slightly confusing

Color Picker (Very bad)

• Not discoverable by tabs
• Dialogue's buttons and fields cannot be tabbed
• Black slider is always read as "selection slider slider 50" regardless of slider value
• All color swatches say "button color swatch", no usable details to distinguish them
• "Color selection area list" (the main rectangle) cannot have its values recognized or read
• The first bar above the big rectangle and to the right of the "use previous color button" is just "clickable", no context, and doesn't seem to have behavior when clicked
• Direct hexcode input, cancel and close, clear and close, HEXA, and RBG buttons all work

Date Edit (Mostly good)

• All the spinners in the non-dialogue are usable, but say "button", which is true because they do open up the dialogue, but may be a bit confusing when they're mostly intended for up-down on keyboard
• AM/PM in the dialogue cannot be spun by using the "up" key, unlike other columns

Date Picker (Very bad)

• Field appears as "edit blank" with no label to indicate usage.
• Nothing indicates that tabbing into it makes the dialogue box appear.
• Keyboards cannot navigate to the dialogue box from the field.
• If you do manage to get into the date picker, keyboard navigation is difficult and reading individual button values is difficult.
• I can't visually understand what's happening through keyboard navigation.

Divider (Good)

• Read out as "separator", which helps translate what's happening

Drag and Drop (Bad, maybe expected)

• Not sure how to help with this one.
• All of the graphics are discoverable through normal page scanning and have their text fields read correctly.
• Screen-reader can't read when you're hovering over a drop zone.
• Can't select an item and then tab through to possible drop zones.

Dropdown (Pitfall)

• Nothing to indicate that the button causes expansion, or the state of the drop down as expanded or collapsed.
• Library consumer's button text would have to indicate purpose and/or state

Field (Pitfalls)

• Reads as "edit blank" while tabbing if it lacks placeholder text, which indicates that the label is not correctly associated with the field.
• Labels and fields scan in their appropriate positions while reading a page out loud.

Figure (Good)

• [EditorRequired] on AlternateText recommended if not already there.

File Edit (Good)

• "Choose file" label is correctly read as part of the whole button, alongside its state, tabble, etc.

File Picker (Good)

• Seems aligned with File Edit

Highlighter (Good)

Image (Good)

• [EditorRequired] on Text recommended if not already there.

Jumbotron (n/a)

Link (Good)

List Group (Pitfall)

• Screen reader cannot recognize selectable items in the demo docs.
• Selectable item lists can't be tabbed to

Mask (Pitfall)

• Behavior seems correct, but no labels are present to test.
• Reads as "edit __-_______" currently, which is helpful but doesn't indicate purpose without a label.

Memo Edit (Pitfall?)

• I'm not able to figure out how to escape the tab override once I tab into it. Some screen readers have keyboard navigation overrides, but I'm not familiar enough to break free of the tab zone.
• Should a tab override come with an escape key override to tab out of it?

Modal (Good)

• Navigation behaves as expected

Offcanvas (Pitfall)

• Relies on developer to explain what the Offcanvas does, since it just appears as a button that has unclear behavior to blind folks
• Blind folks need to figure out it's a dialogue and keyboard navigate / scan /tab into its unexpected position on the screen

Numeric Edit (Pitfall)

• Says "spin button editable", but isn't intended to be clicked (and hitting space to click will often be a bad input or erase it)
• Requires a good label to help clarify the behavior, since the above might be misleading

Numeric Picker (Good-ish)

• Requires a label to explain it, otherwise it's "edit blank" or "edit 123" (when 123 is the current value)

Pagination (Mostly usable)

• Expected tab navigation
• Previous and Next buttons are not discoverable by tabs or during line-by-line scanning.

Progress (Pitfall)

• Indeterminate progress bar cannot be discovered at all by a screen-reader, but the others are good.

Radio (Pitfall and bugged?)

• Radio buttons behave strangely when tabbing on the documentation page for it
• Documentation page seems to treat all radio buttons as part of a single group (test hitting left or right repeatedly after selecting a radio button, you'll continue to the next radio button group).

Rating (Invisible and Unusable)

• Cannot be tabbed onto
• Cannot be read by the screen-reader at all
• Slider-based components with shadow DOMs tend to work best imo.

Repeater (n/a)

Select (Mostly good, Pitfall: "Multiple" bad)

• Which ones are selected during the "Multiple" workflow cannot be confirmed by screen-reader.
• Multiple introduced as a generic list, not a selectable
• Groupings cannot be perceived by screen-readers, but this may be preferable to thinking the grouping's text is selectable

Slider (Good?)

• Cannot test on documentation site behavior of labels, because no labels are given.
• Otherwise, functionality is good and discoverable, just unclear if a label will correctly associate with the slider.

Step (Mostly good, small pitfall)

• Screen reader cannot pick up on the current step (only indicated by color).
• Library consumer should make it clear what step they're on with additional text at the top of the current step.

Switch (Good)

• Behaves exactly the same as a checkbox.

Tab (Good)

Table (Grouping bad, otherwise good)

• Groupings are not tabbable
• Groupings are treated as a single row of text in a table, not an interactable button.
• Expand or collapse state invisible.

Time Edit (Good)

• Small issue where "up" doesn't scroll on AM/PM like the others

Time Picker (Very bad)

• Cannot tab onto the dialogue, can't seem to navigate to the dialogue, etc.
• Left/right keyboard behavior inconsistent if you do get into the dialogue

Toast (Great!)

• Text automatically read by screen-reader, tabbable to close button immediately, fits right between current tab/nav position so right back to where you were.

Tooltip (Invisible)

• Nothing set on tooltip will be picked up by screen readers, even when hovering by mouse

Text Edit (Bad? Pitfall?)

• The primary bad thing is that labels don't seem to be picked up correctly while tabbing the fields, so there's "edit blank" all over this page.
• Some component libraries have placeholder text announced as an "autocomplete" value, which isn't happening here, and may make it seem like this value is actually entered by default.
• Invalidity is not visible to the screen-reader (not sure if fixable)

Typography (Unsure)

• True headings are an important tool for screen readers to enable easier keyboard navigation and jumping around a page based on heading level.
• The component used here seems to create a div with a css style instead of a true heading.
• This is strange because otherwise the documents' headings are behaving correctly.
• Other examples within the document do use a true heading as well.
• List Style Image's image is invisible to screen reader, but is typically unimportant.

Validation (Unsure)

• The validation text is read when scanning the page, but not while tabbing through the fields, which could be a headache for screen reader users.

• Unsure if validation can be made more discoverable to screen reader.

• The validation text is read when scanning the page, but not while tabbing through the fields, which could be a headache for screen reader users.

• Unsure if validation can be made more discoverable to screen reader.

What browsers do you see the problem on?

No response

Any additional comments?

Feel free to split this into individual issues.

When fixing for a screen reader, don't overthink the final output. As long as it covers the major things of "{Label} {Component} {Editable/Expanded/Collapsed} {Value}", or those pieces of information are obvious, it should be good. For example, your highlighted text thing may seem very jarring with how often it announces "start highlight" and "end highlight" (or in/out, something like that) but it seems like it is behaving correctly.

[stsrki]

Thank you, @arazni, for this very detailed report. It will significantly help me once I start work on accessibility improvements.