axe-windows

axe-windows copied to clipboard

Hello,

In our application, we have rectangles (displayed by a sparkline control) that have an area of fewer than 25 pixels (for example, 12x2 pixels).

What would be the suggested approach for handling these elements so that they're not marked as problematic by the Accessibility Insights for Windows tool?

Thank you in advance for your guidance on the matter.

Thank you for using Accessibility Insights for Windows, @dilyantraykov!

We'd love to offer guidance but need some more information from you:

1. It would be most helpful if you could provide an a11yTest file that contains the accessibility errors you are troubleshooting. Please ensure that this file does not contain sensitive or proprietary information.
2. The other way to give us the most context possible would be to create a minimal reproduction of the type of error you are seeing in source code for a sample app. This would allow us to run Accessibility Insights for Windows on our end and better understand the case you are trying to address.
3. Some background and context around the sparkline control you are using would be helpful. What kind of application are you building? What is the use case for displaying this particular control?

Best, Madalyn

The team requires additional author feedback; please review their replies and update this issue accordingly. Thank you for contributing to Accessibility Insights!

BoundingRectangleError.zip TestResults 10-13-22.zip

Hello Madalyn,

Thank you very much for your response!

Please find attached both a small sample project which demonstrates the error, as well as the test results I observe at my end.

To answer point 3. of your inquiry, the RadSparkline control (for WPF applications) is mainly used by our clients to outline trends. I've hardcoded the data for simplicity, but in the common case, it is generated dynamically.

I hope you find this information sufficient to suggest a viable approach for handling this use case. Please let me know if you require any additional information.

@dilyantraykov ,

You can safely ignore this result. It seems legitimately possible for the bounding rectangle of a sparkline to have an area less than 25 pixels.

For those on the A11y Insights team, we should create a heuristic based on the following criteria to avoid running the bounding rectangle area rule on sparklines:

• ItemStatus property matches XPath "<Property Name="DataContext" Value="Telerik.Windows.Controls.Sparklines.SparklineColumnDataPoint" />"
• ControlType = Custom

We should also move this issue to the axe-windows repo.

Here is the full value of the ItemStatus property:

<?xml version="1.0" encoding="utf-16"?><Properties><Property Name="ActualHeight" Value="1.0204081632653062" /><Property Name="ActualWidth" Value="9.1872000000000025" /><Property Name="DataContext" Value="Telerik.Windows.Controls.Sparklines.SparklineColumnDataPoint" /><Property Name="FlowDirection" Value="LeftToRight" /><Property Name="Focusable" Value="True" /><Property Name="HorizontalAlignment" Value="Stretch" /><Property Name="IsFocused" Value="False" /><Property Name="IsVisible" Value="True" /><Property Name="Language" Value="en-us" /><Property Name="Margin" Value="0,0,0,0" /><Property Name="MaxHeight" Value="Infinity" /><Property Name="MaxWidth" Value="Infinity" /><Property Name="MinHeight" Value="0" /><Property Name="MinWidth" Value="0" /><Property Name="Opacity" Value="1" /><Property Name="Tag" /><Property Name="VerticalAlignment" Value="Stretch" /><Property Name="Visibility" Value="Visible" /><Property Name="Background" /><Property Name="BorderBrush" /><Property Name="BorderThickness" Value="0,0,0,0" /><Property Name="FontFamily" Value="Segoe UI" /><Property Name="FontSize" Value="12" /><Property Name="FontStyle" Value="Normal" /><Property Name="FontWeight" Value="Normal" /><Property Name="Foreground" Value="#FF000000" /><Property Name="HorizontalContentAlignment" Value="Left" /><Property Name="IsTabStop" Value="True" /><Property Name="Padding" Value="0,0,0,0" /><Property Name="TabIndex" Value="2147483647" /><Property Name="VerticalContentAlignment" Value="Top" /><Property Name="Fill" Value="#FF5A6378" /></Properties>

This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!

In today's triage discussion, we agreed to update the Condition of the BoundingRectangleSizeReasonable rule to omit WPF controls if their ItemStatus property includes the text <Property Name="DataContext" Value="Telerik.Windows.Controls.Sparklines.SparklineColumnDataPoint" />

@DaveTryon @asksep Mind if I work in this issue?

@chingucoding, You're welcome to work on this issue :)

This is fixed but we need to keep the bug in the resolved state until we actually release the updated package

@dilyantraykov, this has been fixed in Axe.Windows 2.1.0, released today. Please close out at your convenience. Thanks!

The team requires additional author feedback; please review their replies and update this issue accordingly. Thank you for contributing to Accessibility Insights!

This issue has been automatically marked as stale because it is marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. Thank you for contributing to Accessibility Insights!

Hello team,

Please excuse me for the late response and thank you for the effort in creating a fix.

Although this works in our particular scenario, there are other elements that also exhibit such errors which have a different ItemStatus code. I assume that other vendors may also have such issues with similar elements but their ItemStatus values will differ.

Would it be possible to expose some property or other API to mark certain elements to be ignored for checks on a particular rule?

@dilyantraykov, I just saw your request. Adding an API is probably a non-starter. The best way to handle these would be to create a new issue for each class that would potentially fall into this category, then we'll need to evaluate them on a case-by-case basis.