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: Birkir R. Gunnarsson
Date: Nov 11, 2019 2:48PM

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 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.