-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question On Target Size testing specifically in Insights for Windows (not web) #1849
Comments
Hi, this has been open for two weeks, is there any person in particular that can respond to this inquiry? |
This has now been open 3 weeks, can I get a response please? |
Hi Chris, Thanks for the feedback. We are working on documentation for target size. In the meantime, to use, make sure you add the new "LogicalSize" property to your live inspect property view. Once you have added that, then you can follow the guidelines here to ensure you app is meeting standard touch target sizing guidelines. Note that the guidelines referenced are "web" guidelines, but they apply equally as well to Windows/desktop applications. Joe |
Hi @joestegman425 is there a tutorial to understand where to do this in the live inspect property view? I'm looking for plain language type tutorial for general consumption as well as technical. Thanks again! |
@joestegman425 I've added that attribute in to the tool and now see LogicalSize as a property. If I'm looking at property details pane in the tool, I can see that elements have respective values when inspecting. Thank you. I do have a question after adding that property however. Use Case: I'm using your Accessibility Insights tool to review Microsoft Excel's menu button spacing for example. I'm on the Home Menu then evaluating the formatting buttons that read as top align and middle align. With the given output value of w=21 h=22 how would you state a user would take those values per the property you said to add and validate against the SC's recommendation? That is what I'm after. I have reviewed the understanding document prior to reaching out to you. Reading that again, there is Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target. I also see you have a property BoundingRectangle, but that may not be needed in full to understand the spacing. Would those buttons in the formatting menu in your opinion be met by an equivalent or exception? If not, how does Microsoft / Windows Insights recommend taking the LogicalSize output values and evaluating against the SC's intent? Thanks for the discussion. Appreciate your help! |
Hi Chris, LogicalSize width/height equate to a CSS pixel (1/96th of an inch). In your case, you have an element that is "undersized" (per the SC). Undersized elements should have a spacing of at least 24 CSS pixels between adjacent elements. For spacing between undersized elements, the guideline states that if you could draw a 24x24 CSS circle on top of your element that is centered on your element, that circle should not overlap with a similar circle drawn on an adjacent element. This is captured in the image below (from the guideline). Are you looking for a way to validate the spacing between elements for undersized elements (effectively what the picture shows)? If so, that is not a currently supported in the tool. Joe |
@joestegman425 yes, I'm aware of the pass fail examples in WCAG and appreciate you bringing in that part of the conversation. That is exactly what I'm after. I'm wondering 1) if the use case I presented (Excel ribbon/menu formatting buttons) would pass or fail , per inspection with your tool, against the SC. In reading what has been provided to date, this is not fully testable with your tool. I could see that it potentially fails or passes per the examples you've highlighted above in the images, however not certain how your tool would give the 'px' spacing between the two buttons themselves in order to evaluate whether or not the undersized overlap or if they are within the magical threshold of spacing between the two elements. I know we are applying the logic of WCAG to OS Software, I was looking for confirmation on the tooling out there that would offer the same as what we can inspect with Web based tools. If the tool itself can't currently support that feature, it is definitely ok and completely understandable. I was confirming what I thought on what is currently best practice and your tool comes to mind as a leader in the software space to analyze such use cases. If there is a way outside of the 24x24 circle feature layer to evaluate from a logical standpoint of comparing two adjacent elements, with your tool, I'm happy to follow that logic. |
Hi Chris, The tool does not directly support determining spacing between elements but it does provide the information such that you can calculate the spacing. To determine spacing, you can use the BoundingRectangle property with some math. The BoundingRectangle provides the absolute Left, Top, Right and Bottom pixel values for an element and you can use the BoundingRectangles of adjacent elements to determine the pixel offset between those elements (for example Right of one element minus the Left of the adjacent element). Unfortunately, BoundingRectangle is in physical screen pixels vs. logical pixels (CSS pixels) so you'll need to covert between physical pixels and logical pixels to get the correct CSS pixel offset. One easy way to get the scale factor between the two is to use the BoundingRectangle height and width (Top-Bottom and Right-Left) and compare that to the LogicalSize. Joe |
@joestegman425 Thanks for that explanation. Given the math equation you provided, could you use the Microsoft Excel use case as an example with the math and steps listed out? For Button Top Align I have logicalsize of w=21, h=22, the boundingrectangle is l=386,t=83 , r=418,b=117 For Button Middle Align I have logicalsize of w=21, h=22, the boundingrectangle is l=420 ,t=83,r=452,b=117 So with what you stated above, Top Align R = 418 - Middle Align L = 420 = -2. So is the offset = -2? The Top and Bottom are 83 and 117 respectively. With respect to those numbers, the logicalsize of the button is w=21, h=22 , so for scale factor, what exactly are you stating is how to analyze this further? Hypothetically / Figuratively, if I placed a 24x24 circle on the 21 w button, I'd have a potential overlap of 3px? Compared to the distance between the boundingrectangle distance of 2? If the distance is 2 and the potential overlap is 3, would this fail or pass per your math? Thanks for your help to date and for any other clarity you can provide. |
Hi Chris, For your first button, the screen pixel size is w=32, h=34. That element has a CSS pixel size is w=21, h=22 - so your scale factor is ~1.5, 32/21 and 34/22. Scale factor being the ratio between screen pixel size and CSS pixel size (in your case, they are not the same). This is important because any calculations you do with screen pixels (BoundingRectangle) need to be converted to CSS pixels as CSS pixels are a specific physical size (e.g. 1/96 of an inch) while screen pixels physical size varies by monitor. Your buttons are 2 screen pixels apart (420-418). With your scale factor of 1.5, that is 1.3 CSS pixels between them (2/1.5 = 1.3). If you place a hypothetical 24x24 CSS pixel circle on the first button, that circle will overhang the button by 1.5 CSS pixels on either side (since the button has a width of 21, 24-21=3 - meaning the circle will overhang by 1.5 CSS pixels on either side). Given you only have 1.3 CSS pixel spacing between the buttons, that circle will overlap with the adjacent element (and the adjacent element's 24x24 CSS circle given the adjacent element is also only 21 CSS pixels wide). Hopefully that helps, but let me know if you have further questions, |
@joestegman425 , so per the above math and overlap, the buttons mentioned would not pass? Per what you are stating above it reads as they would overlap, and fail. Is that correct? Or is this moot due to the alternative way available to indent, etc.? Thanks for the math lesson either way! |
Hi Chris, Yes, per the data you provided, the elements 24x24 CSS pixel targets sizes would overlap. Joe |
Hi,
I'm wondering if you could provide a tutorial within your documentation or point me to one if it exists on how to use your tool to validate for https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html for Windows? Is this a feature set you rolled out with the newer release? I apologize for not seeing it if so.
The text was updated successfully, but these errors were encountered: