Skip to content
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

A11y Considerations #114

Open
devandanger opened this issue May 4, 2020 · 3 comments
Open

A11y Considerations #114

devandanger opened this issue May 4, 2020 · 3 comments

Comments

@devandanger
Copy link

devandanger commented May 4, 2020

Links or buttons are recommended to have hit targets of 44x44.

Additionally to support this larger hit targets, I need to make a custom AttributedLabel hitTest method for the View to accept hit tests and forward them on to the DetectAreaButton.

I have these implemented as opt-in only, so they shouldn't have any effect on the existing code.
@psharanda would you be interested in these A11y enhancements?

There are a couple voiceover improvements that I'm looking at as well.

@psharanda
Copy link
Owner

Hi @devandanger
Thanks for your interest!
Unfortunately I don't see any way, how we can increase hit area without introducing intersection problem, hit area is already at max size
Screen Shot 2020-05-11 at 23 38 58
But I definitely would like to see your voice over improvements.

@devandanger
Copy link
Author

devandanger commented May 12, 2020

RE:Hit Area. The enhancement would have to be opt-in. And I wouldn't suggest using it in a scenario where you are feeding content in from an external source (like twitter in maybe this case).

If you have a controlled amount of text which you wanted attributed with styles you could opt-in to it by doing the following.

//super simple example of growing it out 20 each way, there are smarter ways but just a gist
detailDescriptionLabel.buttonSizingClosure = { (label, detection, rect) in
             return rect.insetBy(dx: -20, dy: -20)
 }

As you pointed out this would be problematic for the following copy.
image

Which as UX advocates we'll have to avoid this, but it improves the other scenarios where you only have one hit target in there. We use this attributed text a lot as headers to certain form element fields. Links allow us to to give additional context of what we are asking, this is typically ancillary behavior but we are trying to be as inclusive as possible per the WCAG.

Thoughts?

Further code implementation in layoutSubviews of AttributedLabel

            highlightableDetections.forEach { detection in
                let nsrange = NSRange(detection.range, in: attributedText.string)
                textView.layoutManager.enumerateEnclosingRects(forGlyphRange: nsrange, withinSelectedGlyphRange: NSRange(location: NSNotFound, length: 0), in: textView.textContainer, using: { (rect, stop) in
                    if let buttonSizingClosure = self.buttonSizingClosure {
                        let newRect = buttonSizingClosure(self, detection, rect)
                        self.addDetectionAreaButton(frame: newRect, detection: detection, text: String(attributedText.string[detection.range]))
                    } else {
                        self.addDetectionAreaButton(frame: rect, detection: detection, text: String(attributedText.string[detection.range]))
                    }
                })
            }

Outside the frame lines reguired additional hitTest opt-ins on the AttributedText, but I'm looking at different approaches for those.

@psharanda
Copy link
Owner

Looks good, I like it 👍
Do you want to create a PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants