jackstone92/a11yoop

iOS accessibility tools

a11yoop's Issues

Add `notMonitored` status for accessibility features that aren't monitored

Currently, any accessibility features that are not being monitored result in .disabled when queried. This is misleading and there should be a corresponding status for this case.

Improve the ergonomics of accessibility feature representation formatting for analytics

It is not always the case that users will want to represent a sequence of A11yFeature as a params dictionary (using the asAnalyticsParams(prefixedBy:) adapter) for analytics purposes. They may want, for example, only a subset of the enabled features listed as a comma-separated String. Previously, this would require a lot of extra work for the user to filter features provided by the A11yoopMonitor and then format them in whatever way is needed.

While it does not seem beneficial for A11yoop to attempt to provide convenience methods to format A11yFeature in x number of ways, it would be worth extending A11yoopMonitor to provide some additional properties for currently monitored accessibility features that are enabled, disabled and unsupported. This would then allow the user to take that information and format it in whichever way they require (using the asAnalyticsParams(prefixedBy:) adapter, comma-separated or otherwise).

Prevent potential data races on A11yStoreLive

There is currently the possibility for data races when writing to/reading from the A11yStoreLive; particularly as it is possible to specify for the A11yoopMonitor to run on a background queue. This needs addressing.

While a future optimisation might be to opt to use Swift Concurrency and actors, an intermediate fix might be to use thread locking or dispatch queues in order to prevent such data races from occurring.

Add support for watchOS, tvOS and macOS

Package structure overhaul

The package structure of A11yoop needs to be re-evaluated since, while a hyper-modularisation approach works well for app development, it is not necessarily the best approach for libraries that will be consumed outside of a first-party scope.

We want a very simple API contract where the user can only import products like A11yoopMonitor and use publicly available classes/structs without leaking any implementation detail that has been extracted into separate modules (eg. A11yStatusProvider). The biggest issue is that it is currently possible for these to be imported by the consumer. Swift does not currently have a moduleprivate access modifier yet, which is what would have been perfect for this package structure. Until this is available, we need to restructure the package to prevent the leaking of any implementation detail so that we can ensure that only public products are able to be imported.

Update VoiceOver description of A11yoop in preview app

Currently, when using the preview app with VoiceOver enabled, the navigation title is described as "A-11-yoop Preview" rather than "Alleyoop Preview".