E-mail List Archives

Search E-mail List Archives for

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

From: Ramakrishnan Subramanian
Date: Sun, Sep 19 2021 10:48PM
Subject: Any specific Guidance on evaluation methods for WCAG 2.1 SC on Native/hybrid mobile apps?
No previous message | Next message →

Hi
I am sorry if the following topic is already discussed in this group.
I tried searching in the archives but could not find the discussions
happened on this topic.
Any specific Guidance on evaluation methods for following WCAG 2.1 SC
on Native/hybrid mobile apps? In case if there is no appropriate
method to test these requirements how it is supposed to be mentioned
in the ACR against these SC? Can it be marked as ‘NA" instead of ‘Not
supported'?
1.3.5 Identify Input Purpose (AA)
1.4.10 Reflow (AA)
1.4.12 Text Spacing (AA)





--

Thanks and Regards
Ramakrishnan

From: glen walker
Date: Sun, Sep 19 2021 11:57PM
Subject: Re: Any specific Guidance on evaluation methods for WCAG 2.1 SC on Native/hybrid mobile apps?
← Previous message | Next message →

Many success criteria specifically mention "web" in the definition which
technically would rule out native apps. However, many of those SC would
still benefit native app users so it's still helpful to follow as much WCAG
as possible even if it implies the SC is for the web.

In your specific list, 1.3.5 says "The content is implemented using
technologies with support for identifying the expected meaning for form
input data." For native ios and android apps, you can often set the type
of field, such as plain text, numeric, email, phone number, so that the
appropriate onscreen keyboard displays but that's not exactly identifying
the input purpose. So those technologies don't have any support for 1.3.5

1.4.10 doesn't apply since you can't change your mobile device's viewport.

1.4.12 says "In content implemented using markup languages". While that
doesn't imply "web", most markup languages, such as HTML, are typically for
web. I suppose you could have the app written with something like React
Native, but that's essentially a javascript-like language and not really
considered a "markup" language, so it also wouldn't apply.

So your VPAT/ACR could have NA for those guidelines.

Note that the instructions for the ITIC VPAT also say you can put
"supports" instead of NA. It says:

"Note: When filling in the WCAG tables, a response may use 'Supports' where
one might otherwise be inclined to use 'Not Applicable'. This is in
keeping with WCAG 2.0 Understanding Conformance: This means that if there
is no content to which a success criterion applies, the success criterion
is satisfied."


On Sun, Sep 19, 2021 at 10:49 PM Ramakrishnan Subramanian <
= EMAIL ADDRESS REMOVED = > wrote:

> Hi
> I am sorry if the following topic is already discussed in this group.
> I tried searching in the archives but could not find the discussions
> happened on this topic.
> Any specific Guidance on evaluation methods for following WCAG 2.1 SC
> on Native/hybrid mobile apps? In case if there is no appropriate
> method to test these requirements how it is supposed to be mentioned
> in the ACR against these SC? Can it be marked as ‘NA" instead of ‘Not
> supported'?
> 1.3.5 Identify Input Purpose (AA)
> 1.4.10 Reflow (AA)
> 1.4.12 Text Spacing (AA)
>
>
>
>
>
> --
>
> Thanks and Regards
> Ramakrishnan
> > > > >

From: Mitchell Evan
Date: Tue, Sep 21 2021 1:39AM
Subject: Re: Any specific Guidance on evaluation methods for WCAG 2.1 SC on Native/hybrid mobile apps?
← Previous message | No next message

I agree with Glen's recommendations for today, with a caveat that the
situation could change in the future.

According to Section 508 <https://www.access-board.gov/ict/#E205.4> and EN
301 549 <https://en.wikipedia.org/wiki/EN_301_549>, some criteria never
apply to software. In the ITI VPAT
<https://www.itic.org/policy/accessibility/vpat> "INT" edition
(International), column 1 of each WCAG table says which criteria
normatively don't apply. (For better user experience, some criteria such as
3.2.4 Consistent Identification are still a very good idea for apps, even
where the standards don't technically require them.)

Meanwhile, EN 301 549 says these criteria do apply to apps, which
Ramakrishnan asked about:
1.3.5 Identify Input Purpose (AA)
1.4.10 Reflow (AA)
1.4.12 Text Spacing (AA)

For example, criterion 1.4.12 Text Spacing technically applies to web views
in a hybrid app. However, if a pass/fail is currently undetectable for app
testers and makes no difference for app users, then write a remark in the
conformance report explaining that. In the future, be aware that this
situation could change, for example if the iOS or Android operating system
started offering user settings for text spacing.

Similarly, how we evaluate 1.3.5 Identify Input Purpose should change as
soon as there is practical support for input hints in mobile apps.
Developers can already specify them, not only in web views but also in
native app code:

- Autofill hints in Android native code
<https://developer.android.com/reference/androidx/autofill/HintConstants>
- Text content types in iOS native code
<https://developer.apple.com/documentation/uikit/uitextcontenttype>


Mitchell Evan, CPWA
linkedin.com/in/mitchellrevan <https://www.linkedin.com/in/mitchellrevan>
Twitter @mitchellrevan <https://twitter.com/mitchellrevan>
+49 1525 8950540
+1 510 375 6104

---------- Forwarded message ----------
> From: glen walker < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc:
> Bcc:
> Date: Sun, 19 Sep 2021 23:57:33 -0600
> Subject: Re: [WebAIM] Any specific Guidance on evaluation methods for WCAG
> 2.1 SC on Native/hybrid mobile apps?
> Many success criteria specifically mention "web" in the definition which
> technically would rule out native apps. However, many of those SC would
> still benefit native app users so it's still helpful to follow as much WCAG
> as possible even if it implies the SC is for the web.
>
> In your specific list, 1.3.5 says "The content is implemented using
> technologies with support for identifying the expected meaning for form
> input data." For native ios and android apps, you can often set the type
> of field, such as plain text, numeric, email, phone number, so that the
> appropriate onscreen keyboard displays but that's not exactly identifying
> the input purpose. So those technologies don't have any support for 1.3.5
>
> 1.4.10 doesn't apply since you can't change your mobile device's viewport.
>
> 1.4.12 says "In content implemented using markup languages". While that
> doesn't imply "web", most markup languages, such as HTML, are typically for
> web. I suppose you could have the app written with something like React
> Native, but that's essentially a javascript-like language and not really
> considered a "markup" language, so it also wouldn't apply.
>
> So your VPAT/ACR could have NA for those guidelines.
>
> Note that the instructions for the ITIC VPAT also say you can put
> "supports" instead of NA. It says:
>
> "Note: When filling in the WCAG tables, a response may use 'Supports' where
> one might otherwise be inclined to use 'Not Applicable'. This is in
> keeping with WCAG 2.0 Understanding Conformance: This means that if there
> is no content to which a success criterion applies, the success criterion
> is satisfied."
>
>
> On Sun, Sep 19, 2021 at 10:49 PM Ramakrishnan Subramanian <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > Hi
> > I am sorry if the following topic is already discussed in this group.
> > I tried searching in the archives but could not find the discussions
> > happened on this topic.
> > Any specific Guidance on evaluation methods for following WCAG 2.1 SC
> > on Native/hybrid mobile apps? In case if there is no appropriate
> > method to test these requirements how it is supposed to be mentioned
> > in the ACR against these SC? Can it be marked as ‘NA" instead of ‘Not
> > supported'?
> > 1.3.5 Identify Input Purpose (AA)
> > 1.4.10 Reflow (AA)
> > 1.4.12 Text Spacing (AA)
> >
> >
> >
> >
> >
> > --
> >
> > Thanks and Regards
> > Ramakrishnan
> > > > > > > > > >
>
>