WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: can "web page" and "markup language" success criteria be applied to native apps?

for

From: David Engebretson Jr.
Date: Nov 11, 2019 2:51PM

So many good topics here. Thanks for the detailed email! I look forward to
the responses.

As a semi-pro I'd say that it looks like there is inconsistency in the
documentation and it should be modified to fit in with frameworks (native
apps) as well as markup languages.

Again, I appreciate the detail. It helps!

Best,
David

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of glen
walker
Sent: Monday, November 11, 2019 12:47 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: [WebAIM] can "web page" and "markup language" success criteria be
applied to native apps?

This is a somewhat longish question that came about because we were trying
to decide if we could apply 4.1.3 to a native app.

There several WCAG success criteria that say "web pages" and several that
say "markup languages". I presume that means you can have a product that is
built with a "markup language" that is *not* a web page? Is something like
react-native considered a markup language?

In general, WCAG is technology agnostic, but with these two terms, "web
pages" and "markup languages", it seems kind of "gnostic".

Native apps are not web pages (ignoring the fact that a native app might
have a web component in it) so any success criteria that say "web pages"
should not be applied?

What about success criteria that say "markup languages"? Can those be
applied to native apps?

And perhaps too fine of a nit-pick, if one developer uses a structural
language to build a native app and another developer uses a markup language
to build a native app, does the first app not need to check the "markup
language" success criteria but the second app does?

Here are the success criteria that mention "web page":

- 1.4.2 Audio Control - If any audio on a *Web page *plays
automatically...
- 2.3.1 Three Flashes or Below Threshold - *Web pages *do not contain
anything that flashes more than three times...
- 2.4.1 Bypass Blocks - A mechanism is available to bypass blocks of
content that are repeated on multiple *Web pages*.
- 2.4.2 Page Titled - *Web pages *have titles that describe topic or
purpose.
- 2.4.3 Focus Order - If a *Web page *can be navigated sequentially
- 2.4.5 Multiple Ways - More than one way is available to locate a *Web
page *within a set of Web pages...
- 3.1.1 Language of Page - The default human language of each *Web
page...*
- 3.2.3 Consistent Navigation - Navigational mechanisms that are
repeated on multiple *Web pages *within a set of Web pages...
- 3.2.4 Consistent Identification - Components that have the same
functionality within a set of *Web pages*...
- Criterion 3.3.4 Error Prevention (Legal, Financial, Data) - For *Web
pages *that cause...

Here are the success criteria that mention "markup languages" (they all
start the same way):

- 1.3.6 Identify Purpose - In content implemented using markup languages
- 1.4.12 Text Spacing - In content implemented using markup languages
- 4.1.1 Parsing - In content implemented using markup languages
- 4.1.3 Status Messages - In content implemented using markup languages

With a native app, the "focus order" can be just as important as web pages.
When I navigate by swiping (with AT turned on), shouldn't 2.4.3 be applied?
Or maybe that fits better under 1.3.2 Meaningful Sequence. But I could have
a keyboard attached to my mobile device, as discussed on
https://www.w3.org/TR/mobile-accessibility-mapping/#h-keyboard-control-for-t
ouchscreen-devices
so focus order would apply.

Going back to my origin 4.1.3 question. If I'm creating a password and the
password field requires certain conditions (number of characters, special
characters, etc) and those conditions are listed below the field, and as
those conditions are met as I type my new password each condition is checked
off, that's essentially a status message as defined here:
https://www.w3.org/TR/WCAG21/#dfn-status-messages

*"change in content that is not a change of context, and that provides
information to the user on the success or results of an action, on the
waiting state of an application, on the progress of a process, or on the
existence of errors" *

In this case, we are providing information to the user on the result of an
action (they typed a letter that helped satisfy the password requirements).
I would think we'd want these updates announced.

I'm asking because we sometimes get clients that have blinders on and are
super focused on WCAG compliance and if not a strict failure, they often
don't want to fix the issue. I'm sure you've seen companies like that
before.

So, do we have a strict compliance failure in this case?
http://webaim.org/discussion/archives