E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 4 (In chronological order)

From: glen walker
Date: Mon, Nov 11 2019 1:47PM
Subject: can "web page" and "markup language" success criteria be applied to native apps?
No previous message | Next message →

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-touchscreen-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?

From: Birkir R. Gunnarsson
Date: Mon, Nov 11 2019 2:48PM
Subject: Re: can "web page" and "markup language" success criteria be applied to native apps?
← Previous message | Next message →

As much as WCAG can be applied to other forms of electronic
infomration (mostly because it is the only accessibility standard), it
is, at heart, a webcentric standard.
Other forms of electronic communication, such as mobile apps or PDF
documents have platform or program limitations and capabilities that
must be considered when trying to apply WCAG.
For instance, mobile apps have little to no support for data tables
(there is no table object or markup where you can code row or column
headers in a way that they can be announced by a screen reader or
other application in context of the user's navigation).
Mobile app screens are much smaller than most webpages so the whole
idea of having to implement skip mechanisms to jump over blocks of
repeated content do not practically apply for mobile screens, at least
from a practical standpoint.
Screen titles are different from page titles, though you can mostly
apply the concept.
I think the idea of markup language refers to the capabilities of
HTML, if developers choose to bypass HTML in favor of frameworks that
spit out non-semantic HTML, they have to apply ARIA to provide the
missing semantic information, after all people chose not to use the
native markup language for the web in favor of a non-markup language,
so that is a responsibility that falls on the content authors.
For most of the webpage examples, if you just think about them from an
implementation neutral perspective, can be applied to all forms of
electronic communication.
Auto playing audio or video or auto updating content is a user
distraction no matter how it is implemented, ditto flashing or
blinking content.
If you look at the WCAG AG (codenamed silver) draft/work you see the
new approach, the core specification provides technology agnostic
requirements, then there will be modules that applies those
requirements to different forms of technologies (such as web, mobile,
documents).
So, honestly, you need to interpret WCAG in terms of the technical
capabilities and limitations of the platform.
For status messages specifically, both Android and iOS have ways to
announce contents as it is updated (actuallly more easily than the
web), even only for screen readers, so your example can be coded with
status announcements.





On 11/11/19, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> 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-touchscreen-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?
> > > > >


--
Work hard. Have fun. Make history.

From: David Engebretson Jr.
Date: Mon, Nov 11 2019 2:51PM
Subject: Re: can "web page" and "markup language" success criteria be applied to native apps?
← Previous message | Next message →

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

From: Patrick H. Lauke
Date: Mon, Nov 11 2019 3:05PM
Subject: Re: can "web page" and "markup language" success criteria be applied to native apps?
← Previous message | No next message

Strictly, WCAG 2.1 is only directly applicable to web content
technologies https://www.w3.org/TR/WCAG21/#dfn-technologies

Native applications are not based on web technologies (leaving aside
hybrid applications, where the native app contains a built-in user agent
runtime environment and the actual content/functionality uses web
technologies.

So, right from the get-go, I'd say WCAG 2.1 cannot be *directly* applied
to native apps. However, the underlying principles of SCs can still be
applied. For WCAG 2.0 there's the WCAG 2ICT document
https://www.w3.org/WAI/standards-guidelines/wcag/non-web-ict/ ... for
2.1 something similar is still being worked on.

In this light, I'd ignore the "web page" wording and treat that as,
essentially, your "view" in the native application.

More problematic are the SCs that are explicitly scoped to "markup
language" use. (1.3.6 Identify Purpose, 1.4.12 Text Spacing, 4.1.1
Parsing, 4.1.3 Status Messages). Even with the more liberal
reinterpretation (WCAG2ICT) to make things apply to non-web content,
some of those SCs are simply not practical/applicable.

Clearly, 4.1.1 is inapplicable, as native apps don't rely on runtime
parsing of markup which can cause problems...they're already precompiled
and packaged, and there's nothing that can be validated.

1.4.12 Text Spacing, while good in principle, falls down in the case of
native apps because native OSs rarely/never give users high-level
control over/override capabilities for text rendering, the same way
browsers do.

And the granularity required to define purpose for everything for 1.3.6
is not always present in native OSs either (and even 1.3.5, which does
not explicitly mention markup language - strangely enough - is also
already quite problematic at the moment - see
https://github.com/w3c/wcag/issues/720)

For 4.1.3, despite the use of "markup language", I'd actually say that
the *spirit* of the SC can be applied to native apps.

Long story short: as applying WCAG 2.1 to non-web content is already a
reinterpretation of what the SCs are originally intended for, you may as
well creatively reinterpret/ignore bits that say "web page" and "markup
language" ... but also still take a pragmatic view that some of these
SCs, even with this reinterpretation, are simply not realistic to
achieve for native app developers, and treat them as not applicable.

Also, see 508 Refresh, its use of WCAG 2.x, and the exception there:

"EXCEPTION: Non-Web documents shall not be required to conform to the
following four WCAG 2.0 Success Criteria: 2.4.1 Bypass Blocks, 2.4.5
Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent
Identification."

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke