Initial proposal for accessibility identifiers

[bspath-work]

No description provided.

[dimaosipa]

As I mentioned earlier I like the idea. But in automated tests, we need to access various UIViews, which are not tracked. How would we handle accessibility identifiers for them?

[bspath-work]

As I mentioned earlier I like the idea. But in automated tests, we need to access various UIViews, which are not tracked. How would we handle accessibility identifiers for them?

We would need to add identifiers for untracked UIViews. If we use ReportingEvents as the base, they would likely end up being UIEvents that do not get sent to UCR, but do have values for adding accessibility identifiers.

[evgeniyd]

My main concerns here are:

1. We have this proposal in Swift Style Guide, which is not quite related to the style (which is kinda OK, since we don't have other document)
2. We use Accessibility Identifiers for tests, but their names are in a framework that is for reporting which makes things a little bit obscure

[Sky]

As I mentioned earlier I like the idea. But in automated tests, we need to access various UIViews, which are not tracked. How would we handle accessibility identifiers for them?

We would need to add identifiers for untracked UIViews. If we use ReportingEvents as the base, they would likely end up being UIEvents that do not get sent to UCR, but do have values for adding accessibility identifiers.

Not sure if it's good idea considering the fact that we are aiming towards generated reporting constants/events from spec. Also there is probably no need to store accessibility identifiers in some centralized place.
Maybe we should just propose identifier format and add them separately from reporting.

[bspath-work]

As I mentioned earlier I like the idea. But in automated tests, we need to access various UIViews, which are not tracked. How would we handle accessibility identifiers for them?

We would need to add identifiers for untracked UIViews. If we use ReportingEvents as the base, they would likely end up being UIEvents that do not get sent to UCR, but do have values for adding accessibility identifiers.

Not sure if it's good idea considering the fact that we are aiming towards generated reporting constants/events from spec. Also there is probably no need to store accessibility identifiers in some centralized place.
Maybe we should just propose identifier format and add them separately from reporting.

We could, but the structure and functional implementation of a separate format will strongly resemble what we currently already use for reporting, so it's creating additional work to recreate a very similar result.

[bspath-work]

My main concerns here are:

1. We have this proposal in Swift Style Guide, which is not quite related to the style (which is kinda OK, since we don't have other document)

I asked where to propose this. Apparently, this is the best location for now.

2. We use Accessibility Identifiers for tests, but their names are in a framework that is for reporting which makes things a little bit obscure

Accessibility identifiers will be used for more than testing, eventually. This idea leverages the work we've already put into creating identifiers that we currently use for reporting controls and screens.