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

Applicability/testability of 1.3.5 for native apps #720

Closed
patrickhlauke opened this issue May 7, 2019 · 8 comments

Comments

Projects
None yet
5 participants
@patrickhlauke
Copy link
Member

commented May 7, 2019

This falls outside of WCAG itself and into mapping/applicability of 2.1 SCs to non-web technologies, but as an initial sense check:

  • 1.3.5 is quite specific about the "programmatic determined" aspect of input field purpose
  • based on discussions around HTML inputs, we decided that broad strokes type is not sufficiently specific to convey purpose #504 (comment)
  • for native inputs, it's currently only possible to define in very broad strokes when an input is text, a number, phone number, or similar (though it seems some initial work is happening to allow for slightly more specific and granular distinctions - for iOS at least, see https://developer.apple.com/documentation/uikit/uitextcontenttype though it seems this is not programmatically exposed, or at least VO is not doing anything useful with it)
  • the SC is specifically scoped to "implemented using technologies with support for identifying the expected meaning for form input data"

In light of the above, what's the WG's quickfire take on current applicability/testability of 1.3.5 for native applications?

My take is that it's not applicable (yet, until the various platforms allow for more granular programmatic means of conveying purpose, and these are actually exposed and used by applications - as it simply falls fowl of the "technologies with support" bullet).

Which is not to say authors should not still strive to do the right thing in terms of defining inputs in the most specific way they can given the technology (so defining whether an input expects text, or a number, or similar - which as a side effect will trigger the more appropriate on-screen keyboard in the case of smartphone/tablet operating systems)...but that's outside of the scope of 1.3.5.

@johnfoliot

This comment has been minimized.

Copy link

commented May 7, 2019

@mraccess77

This comment has been minimized.

Copy link
Contributor

commented May 7, 2019

I agree as well.

@detlevhfischer

This comment has been minimized.

Copy link
Contributor

commented May 8, 2019

@patrickhlauke

This comment has been minimized.

Copy link
Member Author

commented May 8, 2019

Yes, it's interesting that WCAG 2.1 has been, uncritically, simply added to these guidelines relating to non-web content... (and by "interesting" I of course mean "infuriating"). But hey...

@alastc

This comment has been minimized.

Copy link
Contributor

commented May 8, 2019

it's not applicable (yet, until the various platforms allow for more granular programmatic means of conveying purpose...)

I think that'll be pretty unanimous as it was built into the SC text.

@patrickhlauke Would you like to confirm on a survey? Otherwise feel free to close the issue if you're happy with the response.

@patrickhlauke

This comment has been minimized.

Copy link
Member Author

commented May 8, 2019

Would you like to confirm on a survey?

Nah thanks, I think we're good. Was just after a general sanity check.

So, just to be crystal: once native apps have a mechanism that can signal more granular "purpose" programmatically (and, I would posit, when it's actually exposed programmatically / has some form of actual effect / is accessibility supported), then the SC will become applicable to native, right?

Because https://developer.apple.com/documentation/uikit/uitextcontenttype for instance does look very close to having granular semantics, but it just doesn't seem to be doing anything/exposing anything directly (or at least it's not being taken advantage of, apparently, by any existing password manager/third party helper app, nor is it announced explicitly any differently in VO).

@alastc

This comment has been minimized.

Copy link
Contributor

commented May 8, 2019

That does look quite close and relevant. However, until it becomes accessibility supported (i.e. something can use the info), it's a bit of a tree falling in the woods with no-one to hear.

IMHO: At the point where people can use the info, even just for auto-filling via the browser, then it would become relevant.

Apple appears to be putting the necessary framework into support the functionality, but there is no guarantee it will finish the process or allow for UA support.

@patrickhlauke

This comment has been minimized.

Copy link
Member Author

commented May 8, 2019

Perfect, thanks all for confirming my hunch/take on this. (may be worth keeping a mental note for when/if we create/update the "how WCAG 2.1 maps to native/non-web apps" documentation)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.