Demonstrates iOS SwiftUI Accessibility programming techniques using live good and bad examples that can be tested with VoiceOver and other AT. Includes documentation for developers explaining how to code accessible patterns for iOS.
The data tables documentation is awesome! The only thing I hesitate on is the use of an .accessibilityHint to convey row/column information. The only reason I say that is because there are still users who choose to have hints turned off.
The feedback I have gotten from VoiceOver users is to include the association of header and row within the label for each item.
That way whether hints are turn on/off it is conveyed. Now this does cause other potential issues such as overriding the text of the item in the cell or labels being super long.
Just as a note, I do not condone having the label say "Row " or "Column <xyz". Same as what you got documented :)
I noticed that the "Error Validation" documentation file does not contain a link to the associated coding technique. I think providing a link in the documentation file would make the relevant code easier to discover and navigate to. If others agree, I could help update the documentation files accordingly. Thanks!
IMO, .accessibilityValue is another valid technique to expose an input's helper text and error message. Unlike .accessibilityHint, I don't think users can disable the announcement of an element's .accessibilityValue. This is why I think using .accessibilityValue may be a more robust approach.
My recommendation is to update the Error Validation coding technique (and associated documentation page) to include a "good" example that demonstrates how to use .accessibilityValue.
There are fantastic examples in this repo of using XCTest to perform accessibility related UI tests. I think it would be helpful to provide an overview in a separate markdown file that people can read before diving in to get a high level understanding of this topic.
This explainer could cover things like:
types of issues can you check for: missing labels for elements, lack of support for Dynamic Type, asserting existence of specific semantic accessibility properties/modifiers, etc.
I think having badges example in tabitem would add some good value. As, most homepages that will use tab bar will use the badges to indicate notifications or new information/updates.
Just like in web we expect accordions to have heading role. For disclosure group, we can achieve this by .accessibilityElement(children: .contain)
and then .accessibilityLabel("The disclosure group text").
This will add the heading role, to the disclosure group.