WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: WebAIM-Forum Digest, Vol 198, Issue 14

for

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

From: Ramakrishnan Subramanian
Date: Wed, Sep 22 2021 10:50PM
Subject: WebAIM-Forum Digest, Vol 198, Issue 14
No previous message | Next message →

Thanks Glen and Mitchell for your valuable inputs.


On 9/21/21, = EMAIL ADDRESS REMOVED =
< = EMAIL ADDRESS REMOVED = > wrote:
> Send WebAIM-Forum mailing list submissions to
> = EMAIL ADDRESS REMOVED =
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://list.webaim.org/cgi-bin/mailman/listinfo/webaim-forum
> or, via email, send a message with subject or body 'help' to
> = EMAIL ADDRESS REMOVED =
>
> You can reach the person managing the list at
> = EMAIL ADDRESS REMOVED =
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WebAIM-Forum digest..."
>
>
> Today's Topics:
>
> 1. Re: Any specific Guidance on evaluation methods for WCAG 2.1
> SC on Native/hybrid mobile apps? (Mitchell Evan)
> 2. ANNOUNCEMENT: Information Accessibility Design and Policy
> (IADP) Online Professional Certificate from University of
> Illinois (Jon Gunderson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 21 Sep 2021 09:39:14 +0200
> From: Mitchell Evan < = EMAIL ADDRESS REMOVED = >
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] Any specific Guidance on evaluation methods for
> WCAG 2.1 SC on Native/hybrid mobile apps?
> Message-ID:
> <CAK=xW6uLiCot4A2syqVijhV+ = EMAIL ADDRESS REMOVED = >
> Content-Type: text/plain; charset="UTF-8"
>
> 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
>> > >> > >> > >> > >> >
>>
>>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 21 Sep 2021 12:40:50 -0500
> From: Jon Gunderson < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: [WebAIM] ANNOUNCEMENT: Information Accessibility Design and
> Policy (IADP) Online Professional Certificate from University of
> Illinois
> Message-ID:
> <CA+e1ybuDRgFZaWkjOpyqSvrv9iD+5GGiQLr+ = EMAIL ADDRESS REMOVED = >
> Content-Type: text/plain; charset="UTF-8"
>
> The following online certificate is for people new to IT Accessibility or
> who have come to accessibility from other disciplines and want a more
> comprehensive understanding of disability and accessible design. The
> courses are also an excellent way to prepare for IAAP certification or
> maintenance. One of the most common comments from previous participants is
> the connections they have made with other participants.
>
>
>
> *Information Accessibility Design and Policy (IADP) Online Professional
> Certificate *
>
> College of Applied Health Sciences
>
> University of Illinois
>
>
>
> Register for IADP Certificate Program <http://iadp.ahs.illinois.edu/>;
>
>
>
> First Course starts on 18 October, 2020 (Registration closes on 12 October
> @ noon Central Time).
>
>
>
> *Overview*
>
> The IADP program serves website/web application developers/designers,
> content creators in education and industry, information technology
> specialists, and disability service providers learn the principles of
> accessible information architecture and universal design used in education,
> healthcare, and employment settings. Students will also learn the federal
> and state legal mandates governing information accessibility and their
> relationship to the civil rights of people with disabilities, as well as
> technology accessibility standards, design techniques that adhere to those
> standards, and tools that support validation and evidence of compliance to
> those standards. The IADP professional certificate program consists of 3
> online 8 week courses that can be completed in one academic year, and the
> certificate is available to undergraduate, graduate, degree or non-degree
> seeking students.
>
>
>
> Approved by the International Association of Accessibility Professionals
> <https://www.accessibilityassociation.org/> (IAAP) for CAEC Professional
> Development Credit
> <https://www.accessibilityassociation.org/content.asp?admin=Y&contentidG8#Which%20programs%20are%20pre-approved%20for%20CAEC%20Professional%20Development%20credit%20by%20IAAP?>
> .
>
>
>
>
>
> Jon Gunderson, Ph.D., CPWA
>
> Coordinator of Accessible IT Group
>
> University of Illinois at Urbana/Champaign
>
> 1207 S. Oak Street
>
> Champaign, IL 61820
>
>
>
> Phone: (217) 244-5870
>
> E-mail: = EMAIL ADDRESS REMOVED =
> < = EMAIL ADDRESS REMOVED = ?Subject=Re%3A%20Alternative%20date%20combobox%20grid%20date%20picker%20example%20for%20ARIA%20APG&In-Reply-To=%3CBYAPR11MB3413C2168E1DF82F6E4C7B2CC8BE0%40BYAPR11MB3413.namprd11.prod.outlook.com%3E&References=%3CBYAPR11MB3413C2168E1DF82F6E4C7B2CC8BE0%40BYAPR11MB3413.namprd11.prod.outlook.com%3E>
> <mailto: = EMAIL ADDRESS REMOVED =
> < = EMAIL ADDRESS REMOVED = ?Subject=Re%3A%20Alternative%20date%20combobox%20grid%20date%20picker%20example%20for%20ARIA%20APG&In-Reply-To=%3CBYAPR11MB3413C2168E1DF82F6E4C7B2CC8BE0%40BYAPR11MB3413.namprd11.prod.outlook.com%3E&References=%3CBYAPR11MB3413C2168E1DF82F6E4C7B2CC8BE0%40BYAPR11MB3413.namprd11.prod.outlook.com%3E>
>>
>
> www: https://go.illinois.edu/jongund
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> > > > >
>
> ------------------------------
>
> End of WebAIM-Forum Digest, Vol 198, Issue 14
> *********************************************
>


--

Thanks and Regards
Ramakrishnan

From: Ramakrishnan Subramanian
Date: Wed, Sep 22 2021 10:51PM
Subject: Re: WebAIM-Forum Digest, Vol 198, Issue 14
← Previous message | Next message →

Thanks Glen and Mitchell for your valuable inputs.


On 9/23/21, Ramakrishnan Subramanian < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks Glen and Mitchell for your valuable inputs.
>
>
> On 9/21/21, = EMAIL ADDRESS REMOVED =
> < = EMAIL ADDRESS REMOVED = > wrote:
>> Send WebAIM-Forum mailing list submissions to
>> = EMAIL ADDRESS REMOVED =
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://list.webaim.org/cgi-bin/mailman/listinfo/webaim-forum
>> or, via email, send a message with subject or body 'help' to
>> = EMAIL ADDRESS REMOVED =
>>
>> You can reach the person managing the list at
>> = EMAIL ADDRESS REMOVED =
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of WebAIM-Forum digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Any specific Guidance on evaluation methods for WCAG 2.1
>> SC on Native/hybrid mobile apps? (Mitchell Evan)
>> 2. ANNOUNCEMENT: Information Accessibility Design and Policy
>> (IADP) Online Professional Certificate from University of
>> Illinois (Jon Gunderson)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 21 Sep 2021 09:39:14 +0200
>> From: Mitchell Evan < = EMAIL ADDRESS REMOVED = >
>> To: = EMAIL ADDRESS REMOVED =
>> Subject: Re: [WebAIM] Any specific Guidance on evaluation methods for
>> WCAG 2.1 SC on Native/hybrid mobile apps?
>> Message-ID:
>> <CAK=xW6uLiCot4A2syqVijhV+ = EMAIL ADDRESS REMOVED = >
>> Content-Type: text/plain; charset="UTF-8"
>>
>> 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
>>> > >>> > >>> > >>> > >>> >
>>>
>>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 21 Sep 2021 12:40:50 -0500
>> From: Jon Gunderson < = EMAIL ADDRESS REMOVED = >
>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> Subject: [WebAIM] ANNOUNCEMENT: Information Accessibility Design and
>> Policy (IADP) Online Professional Certificate from University of
>> Illinois
>> Message-ID:
>> <CA+e1ybuDRgFZaWkjOpyqSvrv9iD+5GGiQLr+ = EMAIL ADDRESS REMOVED = >
>> Content-Type: text/plain; charset="UTF-8"
>>
>> The following online certificate is for people new to IT Accessibility or
>> who have come to accessibility from other disciplines and want a more
>> comprehensive understanding of disability and accessible design. The
>> courses are also an excellent way to prepare for IAAP certification or
>> maintenance. One of the most common comments from previous participants
>> is
>> the connections they have made with other participants.
>>
>>
>>
>> *Information Accessibility Design and Policy (IADP) Online Professional
>> Certificate *
>>
>> College of Applied Health Sciences
>>
>> University of Illinois
>>
>>
>>
>> Register for IADP Certificate Program <http://iadp.ahs.illinois.edu/>;
>>
>>
>>
>> First Course starts on 18 October, 2020 (Registration closes on 12
>> October
>> @ noon Central Time).
>>
>>
>>
>> *Overview*
>>
>> The IADP program serves website/web application developers/designers,
>> content creators in education and industry, information technology
>> specialists, and disability service providers learn the principles of
>> accessible information architecture and universal design used in
>> education,
>> healthcare, and employment settings. Students will also learn the federal
>> and state legal mandates governing information accessibility and their
>> relationship to the civil rights of people with disabilities, as well as
>> technology accessibility standards, design techniques that adhere to
>> those
>> standards, and tools that support validation and evidence of compliance
>> to
>> those standards. The IADP professional certificate program consists of 3
>> online 8 week courses that can be completed in one academic year, and the
>> certificate is available to undergraduate, graduate, degree or non-degree
>> seeking students.
>>
>>
>>
>> Approved by the International Association of Accessibility Professionals
>> <https://www.accessibilityassociation.org/> (IAAP) for CAEC Professional
>> Development Credit
>> <https://www.accessibilityassociation.org/content.asp?admin=Y&contentidG8#Which%20programs%20are%20pre-approved%20for%20CAEC%20Professional%20Development%20credit%20by%20IAAP?>
>> .
>>
>>
>>
>>
>>
>> Jon Gunderson, Ph.D., CPWA
>>
>> Coordinator of Accessible IT Group
>>
>> University of Illinois at Urbana/Champaign
>>
>> 1207 S. Oak Street
>>
>> Champaign, IL 61820
>>
>>
>>
>> Phone: (217) 244-5870
>>
>> E-mail: = EMAIL ADDRESS REMOVED =
>> < = EMAIL ADDRESS REMOVED = ?Subject=Re%3A%20Alternative%20date%20combobox%20grid%20date%20picker%20example%20for%20ARIA%20APG&In-Reply-To=%3CBYAPR11MB3413C2168E1DF82F6E4C7B2CC8BE0%40BYAPR11MB3413.namprd11.prod.outlook.com%3E&References=%3CBYAPR11MB3413C2168E1DF82F6E4C7B2CC8BE0%40BYAPR11MB3413.namprd11.prod.outlook.com%3E>
>> <mailto: = EMAIL ADDRESS REMOVED =
>> < = EMAIL ADDRESS REMOVED = ?Subject=Re%3A%20Alternative%20date%20combobox%20grid%20date%20picker%20example%20for%20ARIA%20APG&In-Reply-To=%3CBYAPR11MB3413C2168E1DF82F6E4C7B2CC8BE0%40BYAPR11MB3413.namprd11.prod.outlook.com%3E&References=%3CBYAPR11MB3413C2168E1DF82F6E4C7B2CC8BE0%40BYAPR11MB3413.namprd11.prod.outlook.com%3E>
>>>
>>
>> www: https://go.illinois.edu/jongund
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> >> >> >> >>
>>
>> ------------------------------
>>
>> End of WebAIM-Forum Digest, Vol 198, Issue 14
>> *********************************************
>>
>
>
> --
>
> Thanks and Regards
> Ramakrishnan
>


--

Thanks and Regards
Ramakrishnan

From: Ramakrishnan Subramanian
Date: Sat, Sep 25 2021 7:22PM
Subject: Re: WebAIM-Forum Digest, Vol 198, Issue 18
← Previous message | Next message →

First of all, Thanks all for your responses based on broader aspect of
the Accessibility testing.
"By contrast, if you are doing an "accessibility review" or "assistive
technology testing", then you should indeed report that the input
type="date" element is difficult or impossible to use with Voiceover
and Dragon."
@Steve, in this case will you consider this as a user agent issue or
WCAG violation?
Considering the end goal is to meet the legal requirements like ADA
which do not have its own standard. should the dev be forced to try
fixing these (User agent) issues?



On 9/25/21, = EMAIL ADDRESS REMOVED =
< = EMAIL ADDRESS REMOVED = > wrote:
> Send WebAIM-Forum mailing list submissions to
> = EMAIL ADDRESS REMOVED =
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://list.webaim.org/cgi-bin/mailman/listinfo/webaim-forum
> or, via email, send a message with subject or body 'help' to
> = EMAIL ADDRESS REMOVED =
>
> You can reach the person managing the list at
> = EMAIL ADDRESS REMOVED =
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WebAIM-Forum digest..."
>
>
> Today's Topics:
>
> 1. Re: Testing SC 1.4.12 in multiple browsers (Graham Armfield)
> 2. Re: Testing SC 1.4.12 in multiple browsers (Steve Green)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 25 Sep 2021 11:11:40 +0100
> From: Graham Armfield < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers
> Message-ID:
> <CAKr-9+nUQs_iZ1APqLzK+ = EMAIL ADDRESS REMOVED = >
> Content-Type: text/plain; charset="UTF-8"
>
> Wolfgang said...
>
>
>
> *2. Can we blame problems resulting out of bad behavior of browser or
> AT?a) If elements and attributes of HTML, CSS or ARIA are used according to
> the spec, can this ever be considered as failure in an *audit*?*
>
> I think this is a very good question. And in some ways we do have to take
> some view on this when reviewing websites for accessibility.
>
> One example would be the use of input type="date". This input type has been
> in the HTML5 spec for a good few years now, and in many browsers, with many
> ATs it can provide a fully accessible way of allowing users to select a
> date - including a date picker.
>
> But I believe that it's still not really supported in Safari on macOS, and
> it can be a difficult control to interact with when using Dragon
> NaturallySpeaking.
>
> There is an outstanding issue on Apple, but last time I looked there seemed
> to have been no movement. I also contacted Nuance about Dragon and they
> seemed less than interested.
>
> So, if we're reviewing or auditing a site that uses this date input, what's
> the best approach?
>
> Regards
> Graham Armfield
> Coolfields Consulting
>
>
>
> On Fri, 24 Sep 2021, 15:31 , < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Thanks Glen, a good list for reflection!
>>
>> 1. I just thought of adding 4.1.1 to detect bad behavior of browsers
>> and/or AT by testing with SR.
>>
>> E-g- I remember aria-errormessage to be hardly supported.
>> Would the usage despite support touch 4.1.1?
>>
>> 2. Can we blame problems resulting out of bad behavior of browser or AT?
>>
>> a) If elements and attributes of HTML, CSS or ARIA are used according to
>> the spec, can this ever be considered as failure in an *audit*?
>>
>> b) To which degree do we have to respect bad behavior in a *development
>> process"?
>>
>> Wolfgang
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
>> Steve Green
>> Sent: Thursday, September 23, 2021 6:01 PM
>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers
>>
>> While agreeing with Glen, I would take a slightly harder line. The WCAG
>> success criteria do not mention the behaviour with screen readers or any
>> other assistive technology. You do not need to use any assistive
>> technologies at all when doing a WCAG audit. In just about every case,
>> your
>> pass / fail decision MUST be based on manual inspection of the code and
>> user interface. Tools and assistive technologies can provide useful
>> support, but they are often wrong or misleading.
>>
>> Some time ago, I went through all the WCAG success criteria to determine
>> which ones need to be tested with more than one browser. Glen has already
>> mentioned some for which that would not be necessary. I reckon that of the
>> 50 level AA success criteria, only these 7 need to be tested with multiple
>> browsers as a matter of routine:
>>
>> SC 2.1.1: Keyboard Navigation (level A)
>> SC 2.1.2: No Keyboard Trap (level A)
>> SC 2.4.1: Bypass Blocks (level A)
>> SC 2.4.3: Focus Order (level A)
>> SC 1.4.4: Resize Text (level AA)
>> SC 1.4.10: Reflow (level AA)
>> SC 1.4.11: Non-text Contrast (level AA)
>>
>> Depending on how the website is coded, it may be necessary to test other
>> success criteria with multiple browsers. That's usually an indication that
>> the code is pretty horrid.
>>
>> It might even be safe to drop SC 2.4.1 (Bypass Blocks) from that list.
>> Some browsers used to scroll the page but not move the focus position when
>> in-page links were operated, but I don't know if that is still true.
>>
>> I don't recall getting different results from different browsers with any
>> of the other 43 success criteria, so I would be very interested to hear if
>> anyone else has. Even if there are a few more, anyone who is testing all
>> 50
>> in multiple browsers is wasting an awful lot of time.
>>
>> Note that I am not arguing against testing with assistive technologies.
>> It's just that doing so constitutes an "accessibility test", which can be
>> anything you want it to be, not an audit for WCAG conformance, which has a
>> defined scope.
>>
>> Steve Green
>> Managing Director
>> Test Partners Ltd
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
>> glen walker
>> Sent: 23 September 2021 16:06
>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers
>>
>> In theory, your application should work in every browser (firefox, safari,
>> chrome, edge, ie, opera) on every platform (mac, pc, mobile) with every
>> assistive technology (nvda, jaws, narrator, dragon, switch, talkback) at
>> every CSS breakpoint.
>>
>> With unlimited budget and time, you could test every combination. But for
>> practical reasons, the testing is usually "limited" to a few combinations
>> (or even one combination in extreme cases). I say "limited" but that's
>> with respect to the various combinations. It's not limited in how
>> extensive the testing is regarding testing every element on the page.
>>
>> More often than not, an accessibility issue that occurs with one
>> combination will also appear in a different combination. An image missing
>> alt text is going to be a problem no matter what browser you're testing
>> on. A list that is not semantic will be a problem no matter what browser
>> you're testing on. A table without headers is going to be a problem no
>> matter what browser you're testing on.
>>
>> There are, of course, minor differences between the various combinations
>> so sometimes you can find a problem with one that doesn't exist on
>> another.
>> For example, having something like "first name <input>" will show up as a
>> problem when testing with NVDA on both chrome and firefox but if you test
>> with JAWS, it reads ok on chrome (but not firefox). So if you were only
>> testing JAWS on chrome, you might miss the problem. (This is why I
>> usually
>> look at the code too and not rely solely on a screen reader to find
>> issues. Even if a form reads ok, I typically look at the html to see if
>> the label is really associated with the field.)
>>
>> Another difference between browsers is if you have a scrollable container
>> (overflow). When a container has a scrollbar, firefox makes that
>> container
>> a tab stop but chrome does not. So now you have a tab stop that
>> potentially does not have a name or role. It could be confusing for a
>> screen reader user on firefox.
>>
>> I know this is all digressing a bit from your original question, asking if
>> you needed to test 1.4.12 in all browsers. The short answer is "yes" -
>> test everywhere, or at least as much as possible.
>>
>> In your particular case, I have not seen a problem with the Stylus plugin
>> *not* applying to iframes. I *do* see the problem with the bookmarklet
>> not applying to iframes. So Stylus should work if you want to test for
>> 1.4.12. I edited my style and added the same code that the bookmarklet
>> uses:
>>
>> * {
>> line-height: 1.5 !important;
>> letter-spacing: 0.12em !important;
>> word-spacing: 0.16em !important;
>> }
>> p{ margin-bottom: 2em !important;}
>>
>> When I viewed a page with an <iframe>, the styles were applied to the
>> iframe. You can test it with
>> https://www.w3schools.com/html/tryit.asp?filename=tryhtml_iframe_height_width
>> .
>> It has 2 nested iframes.
>> >> >> at http://webaim.org/discussion/archives
>> >> >> >> at http://webaim.org/discussion/archives
>> >>
>> >> >> >> >>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 25 Sep 2021 13:25:06 +0000
> From: Steve Green < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers
> Message-ID:
> < = EMAIL ADDRESS REMOVED = >
>
> Content-Type: text/plain; charset="utf-8"
>
> "So, if we're reviewing or auditing a site that uses this date input, what's
> the best approach?"
>
> It all depends on what you mean by "reviewing or auditing a site". Are you
> testing for WCAG conformance or are you testing the user experience? They
> are not the same.
>
> If you are doing a WCAG audit, my view is that it passes. The input
> type="date" element is accessibility supported as per the definition at
> https://www.w3.org/WAI/WCAG21/Understanding/conformance#accessibility-supported-definition
>
> The definition does not require that the Web content technology is supported
> by ALL user agents as long as it "is supported natively in
> widely-distributed user agents". In fact it goes further and says "The
> Accessibility Guidelines Working Group and the W3C do not specify which or
> how much support by assistive technologies there must be for a particular
> use of a Web technology in order for it to be classified as accessibility
> supported."
>
> By contrast, if you are doing an "accessibility review" or "assistive
> technology testing", then you should indeed report that the input
> type="date" element is difficult or impossible to use with Voiceover and
> Dragon.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Graham Armfield
> Sent: 25 September 2021 11:12
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers
>
> Wolfgang said...
>
>
>
> *2. Can we blame problems resulting out of bad behavior of browser or
> AT?a) If elements and attributes of HTML, CSS or ARIA are used according to
> the spec, can this ever be considered as failure in an *audit*?*
>
> I think this is a very good question. And in some ways we do have to take
> some view on this when reviewing websites for accessibility.
>
> One example would be the use of input type="date". This input type has been
> in the HTML5 spec for a good few years now, and in many browsers, with many
> ATs it can provide a fully accessible way of allowing users to select a date
> - including a date picker.
>
> But I believe that it's still not really supported in Safari on macOS, and
> it can be a difficult control to interact with when using Dragon
> NaturallySpeaking.
>
> There is an outstanding issue on Apple, but last time I looked there seemed
> to have been no movement. I also contacted Nuance about Dragon and they
> seemed less than interested.
>
> So, if we're reviewing or auditing a site that uses this date input, what's
> the best approach?
>
> Regards
> Graham Armfield
> Coolfields Consulting
>
>
>
> On Fri, 24 Sep 2021, 15:31 , < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Thanks Glen, a good list for reflection!
>>
>> 1. I just thought of adding 4.1.1 to detect bad behavior of browsers
>> and/or AT by testing with SR.
>>
>> E-g- I remember aria-errormessage to be hardly supported.
>> Would the usage despite support touch 4.1.1?
>>
>> 2. Can we blame problems resulting out of bad behavior of browser or AT?
>>
>> a) If elements and attributes of HTML, CSS or ARIA are used according
>> to the spec, can this ever be considered as failure in an *audit*?
>>
>> b) To which degree do we have to respect bad behavior in a
>> *development process"?
>>
>> Wolfgang
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
>> Steve Green
>> Sent: Thursday, September 23, 2021 6:01 PM
>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers
>>
>> While agreeing with Glen, I would take a slightly harder line. The
>> WCAG success criteria do not mention the behaviour with screen readers
>> or any other assistive technology. You do not need to use any
>> assistive technologies at all when doing a WCAG audit. In just about
>> every case, your pass / fail decision MUST be based on manual
>> inspection of the code and user interface. Tools and assistive
>> technologies can provide useful support, but they are often wrong or
>> misleading.
>>
>> Some time ago, I went through all the WCAG success criteria to
>> determine which ones need to be tested with more than one browser.
>> Glen has already mentioned some for which that would not be necessary.
>> I reckon that of the
>> 50 level AA success criteria, only these 7 need to be tested with
>> multiple browsers as a matter of routine:
>>
>> SC 2.1.1: Keyboard Navigation (level A) SC 2.1.2: No Keyboard Trap
>> (level A) SC 2.4.1: Bypass Blocks (level A) SC 2.4.3: Focus Order
>> (level A) SC 1.4.4: Resize Text (level AA) SC 1.4.10: Reflow (level
>> AA) SC 1.4.11: Non-text Contrast (level AA)
>>
>> Depending on how the website is coded, it may be necessary to test
>> other success criteria with multiple browsers. That's usually an
>> indication that the code is pretty horrid.
>>
>> It might even be safe to drop SC 2.4.1 (Bypass Blocks) from that list.
>> Some browsers used to scroll the page but not move the focus position
>> when in-page links were operated, but I don't know if that is still true.
>>
>> I don't recall getting different results from different browsers with
>> any of the other 43 success criteria, so I would be very interested to
>> hear if anyone else has. Even if there are a few more, anyone who is
>> testing all 50 in multiple browsers is wasting an awful lot of time.
>>
>> Note that I am not arguing against testing with assistive technologies.
>> It's just that doing so constitutes an "accessibility test", which can
>> be anything you want it to be, not an audit for WCAG conformance,
>> which has a defined scope.
>>
>> Steve Green
>> Managing Director
>> Test Partners Ltd
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
>> glen walker
>> Sent: 23 September 2021 16:06
>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers
>>
>> In theory, your application should work in every browser (firefox,
>> safari, chrome, edge, ie, opera) on every platform (mac, pc, mobile)
>> with every assistive technology (nvda, jaws, narrator, dragon, switch,
>> talkback) at every CSS breakpoint.
>>
>> With unlimited budget and time, you could test every combination. But
>> for practical reasons, the testing is usually "limited" to a few
>> combinations (or even one combination in extreme cases). I say
>> "limited" but that's with respect to the various combinations. It's
>> not limited in how extensive the testing is regarding testing every
>> element on the page.
>>
>> More often than not, an accessibility issue that occurs with one
>> combination will also appear in a different combination. An image
>> missing alt text is going to be a problem no matter what browser
>> you're testing on. A list that is not semantic will be a problem no
>> matter what browser you're testing on. A table without headers is
>> going to be a problem no matter what browser you're testing on.
>>
>> There are, of course, minor differences between the various
>> combinations so sometimes you can find a problem with one that doesn't
>> exist on another.
>> For example, having something like "first name <input>" will show up
>> as a problem when testing with NVDA on both chrome and firefox but if
>> you test with JAWS, it reads ok on chrome (but not firefox). So if
>> you were only testing JAWS on chrome, you might miss the problem.
>> (This is why I usually look at the code too and not rely solely on a
>> screen reader to find issues. Even if a form reads ok, I typically
>> look at the html to see if the label is really associated with the
>> field.)
>>
>> Another difference between browsers is if you have a scrollable
>> container (overflow). When a container has a scrollbar, firefox makes
>> that container a tab stop but chrome does not. So now you have a tab
>> stop that potentially does not have a name or role. It could be
>> confusing for a screen reader user on firefox.
>>
>> I know this is all digressing a bit from your original question,
>> asking if you needed to test 1.4.12 in all browsers. The short answer
>> is "yes" - test everywhere, or at least as much as possible.
>>
>> In your particular case, I have not seen a problem with the Stylus
>> plugin
>> *not* applying to iframes. I *do* see the problem with the
>> bookmarklet not applying to iframes. So Stylus should work if you
>> want to test for 1.4.12. I edited my style and added the same code
>> that the bookmarklet
>> uses:
>>
>> * {
>> line-height: 1.5 !important;
>> letter-spacing: 0.12em !important;
>> word-spacing: 0.16em !important;
>> }
>> p{ margin-bottom: 2em !important;}
>>
>> When I viewed a page with an <iframe>, the styles were applied to the
>> iframe. You can test it with
>> https://www.w3schools.com/html/tryit.asp?filename=tryhtml_iframe_heigh
>> t_width
>> .
>> It has 2 nested iframes.
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
> > > http://webaim.org/discussion/archives
> >
> ------------------------------
>
> Subject: Digest Footer
>
> > > > >
>
> ------------------------------
>
> End of WebAIM-Forum Digest, Vol 198, Issue 18
> *********************************************
>


--

Thanks and Regards
Ramakrishnan

From: Steve Green
Date: Sun, Sep 26 2021 1:56PM
Subject: Re: WebAIM-Forum Digest, Vol 198, Issue 18
← Previous message | No next message

In my view, it is not a WCAG non-conformance. Obviously, you can't fix user agent issues, so the question is whether you can avoid them and what compromises would need to be made. It may just be a matter of time and cost, but sometimes an alternative approach has an impact on the appearance and behaviour.

It is the responsibility of the product owner and other stakeholders to decide whether anything should be done and what compromises are acceptable. It is absolutely not the responsibility of the accessibility tester to do that. Your responsibility is to provide the stakeholders with all the information they need to make an informed decision.

Steve


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Ramakrishnan Subramanian
Sent: 26 September 2021 02:23
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] WebAIM-Forum Digest, Vol 198, Issue 18

First of all, Thanks all for your responses based on broader aspect of the Accessibility testing.
"By contrast, if you are doing an "accessibility review" or "assistive technology testing", then you should indeed report that the input type="date" element is difficult or impossible to use with Voiceover and Dragon."
@Steve, in this case will you consider this as a user agent issue or WCAG violation?
Considering the end goal is to meet the legal requirements like ADA which do not have its own standard. should the dev be forced to try fixing these (User agent) issues?



On 9/25/21, = EMAIL ADDRESS REMOVED =
< = EMAIL ADDRESS REMOVED = > wrote:
> Send WebAIM-Forum mailing list submissions to
> = EMAIL ADDRESS REMOVED =
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://list.webaim.org/cgi-bin/mailman/listinfo/webaim-forum
> or, via email, send a message with subject or body 'help' to
> = EMAIL ADDRESS REMOVED =
>
> You can reach the person managing the list at
> = EMAIL ADDRESS REMOVED =
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WebAIM-Forum digest..."
>
>
> Today's Topics:
>
> 1. Re: Testing SC 1.4.12 in multiple browsers (Graham Armfield)
> 2. Re: Testing SC 1.4.12 in multiple browsers (Steve Green)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 25 Sep 2021 11:11:40 +0100
> From: Graham Armfield < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers
> Message-ID:
> <CAKr-9+nUQs_iZ1APqLzK+ = EMAIL ADDRESS REMOVED = >
> Content-Type: text/plain; charset="UTF-8"
>
> Wolfgang said...
>
>
>
> *2. Can we blame problems resulting out of bad behavior of browser or
> AT?a) If elements and attributes of HTML, CSS or ARIA are used
> according to the spec, can this ever be considered as failure in an
> *audit*?*
>
> I think this is a very good question. And in some ways we do have to
> take some view on this when reviewing websites for accessibility.
>
> One example would be the use of input type="date". This input type has
> been in the HTML5 spec for a good few years now, and in many browsers,
> with many ATs it can provide a fully accessible way of allowing users
> to select a date - including a date picker.
>
> But I believe that it's still not really supported in Safari on macOS,
> and it can be a difficult control to interact with when using Dragon
> NaturallySpeaking.
>
> There is an outstanding issue on Apple, but last time I looked there
> seemed to have been no movement. I also contacted Nuance about Dragon
> and they seemed less than interested.
>
> So, if we're reviewing or auditing a site that uses this date input,
> what's the best approach?
>
> Regards
> Graham Armfield
> Coolfields Consulting
>
>
>
> On Fri, 24 Sep 2021, 15:31 , < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Thanks Glen, a good list for reflection!
>>
>> 1. I just thought of adding 4.1.1 to detect bad behavior of browsers
>> and/or AT by testing with SR.
>>
>> E-g- I remember aria-errormessage to be hardly supported.
>> Would the usage despite support touch 4.1.1?
>>
>> 2. Can we blame problems resulting out of bad behavior of browser or AT?
>>
>> a) If elements and attributes of HTML, CSS or ARIA are used according
>> to the spec, can this ever be considered as failure in an *audit*?
>>
>> b) To which degree do we have to respect bad behavior in a
>> *development process"?
>>
>> Wolfgang
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf
>> Of Steve Green
>> Sent: Thursday, September 23, 2021 6:01 PM
>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers
>>
>> While agreeing with Glen, I would take a slightly harder line. The
>> WCAG success criteria do not mention the behaviour with screen
>> readers or any other assistive technology. You do not need to use any
>> assistive technologies at all when doing a WCAG audit. In just about
>> every case, your pass / fail decision MUST be based on manual
>> inspection of the code and user interface. Tools and assistive
>> technologies can provide useful support, but they are often wrong or
>> misleading.
>>
>> Some time ago, I went through all the WCAG success criteria to
>> determine which ones need to be tested with more than one browser.
>> Glen has already mentioned some for which that would not be
>> necessary. I reckon that of the
>> 50 level AA success criteria, only these 7 need to be tested with
>> multiple browsers as a matter of routine:
>>
>> SC 2.1.1: Keyboard Navigation (level A) SC 2.1.2: No Keyboard Trap
>> (level A) SC 2.4.1: Bypass Blocks (level A) SC 2.4.3: Focus Order
>> (level A) SC 1.4.4: Resize Text (level AA) SC 1.4.10: Reflow (level
>> AA) SC 1.4.11: Non-text Contrast (level AA)
>>
>> Depending on how the website is coded, it may be necessary to test
>> other success criteria with multiple browsers. That's usually an
>> indication that the code is pretty horrid.
>>
>> It might even be safe to drop SC 2.4.1 (Bypass Blocks) from that list.
>> Some browsers used to scroll the page but not move the focus position
>> when in-page links were operated, but I don't know if that is still true.
>>
>> I don't recall getting different results from different browsers with
>> any of the other 43 success criteria, so I would be very interested
>> to hear if anyone else has. Even if there are a few more, anyone who
>> is testing all
>> 50
>> in multiple browsers is wasting an awful lot of time.
>>
>> Note that I am not arguing against testing with assistive technologies.
>> It's just that doing so constitutes an "accessibility test", which
>> can be anything you want it to be, not an audit for WCAG conformance,
>> which has a defined scope.
>>
>> Steve Green
>> Managing Director
>> Test Partners Ltd
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf
>> Of glen walker
>> Sent: 23 September 2021 16:06
>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers
>>
>> In theory, your application should work in every browser (firefox,
>> safari, chrome, edge, ie, opera) on every platform (mac, pc, mobile)
>> with every assistive technology (nvda, jaws, narrator, dragon,
>> switch, talkback) at every CSS breakpoint.
>>
>> With unlimited budget and time, you could test every combination.
>> But for practical reasons, the testing is usually "limited" to a few
>> combinations (or even one combination in extreme cases). I say
>> "limited" but that's with respect to the various combinations. It's
>> not limited in how extensive the testing is regarding testing every element on the page.
>>
>> More often than not, an accessibility issue that occurs with one
>> combination will also appear in a different combination. An image
>> missing alt text is going to be a problem no matter what browser
>> you're testing on. A list that is not semantic will be a problem no
>> matter what browser you're testing on. A table without headers is
>> going to be a problem no matter what browser you're testing on.
>>
>> There are, of course, minor differences between the various
>> combinations so sometimes you can find a problem with one that
>> doesn't exist on another.
>> For example, having something like "first name <input>" will show up
>> as a problem when testing with NVDA on both chrome and firefox but if
>> you test with JAWS, it reads ok on chrome (but not firefox). So if
>> you were only testing JAWS on chrome, you might miss the problem.
>> (This is why I usually look at the code too and not rely solely on a
>> screen reader to find issues. Even if a form reads ok, I typically
>> look at the html to see if the label is really associated with the
>> field.)
>>
>> Another difference between browsers is if you have a scrollable
>> container (overflow). When a container has a scrollbar, firefox
>> makes that container a tab stop but chrome does not. So now you have
>> a tab stop that potentially does not have a name or role. It could
>> be confusing for a screen reader user on firefox.
>>
>> I know this is all digressing a bit from your original question,
>> asking if you needed to test 1.4.12 in all browsers. The short
>> answer is "yes" - test everywhere, or at least as much as possible.
>>
>> In your particular case, I have not seen a problem with the Stylus
>> plugin
>> *not* applying to iframes. I *do* see the problem with the
>> bookmarklet not applying to iframes. So Stylus should work if you
>> want to test for 1.4.12. I edited my style and added the same code
>> that the bookmarklet
>> uses:
>>
>> * {
>> line-height: 1.5 !important;
>> letter-spacing: 0.12em !important;
>> word-spacing: 0.16em !important;
>> }
>> p{ margin-bottom: 2em !important;}
>>
>> When I viewed a page with an <iframe>, the styles were applied to the
>> iframe. You can test it with
>> https://www.w3schools.com/html/tryit.asp?filename=tryhtml_iframe_heig
>> ht_width
>> .
>> It has 2 nested iframes.
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 25 Sep 2021 13:25:06 +0000
> From: Steve Green < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers
> Message-ID:
>
> < = EMAIL ADDRESS REMOVED =
> tlook.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> "So, if we're reviewing or auditing a site that uses this date input,
> what's the best approach?"
>
> It all depends on what you mean by "reviewing or auditing a site". Are
> you testing for WCAG conformance or are you testing the user
> experience? They are not the same.
>
> If you are doing a WCAG audit, my view is that it passes. The input
> type="date" element is accessibility supported as per the definition
> at
> https://www.w3.org/WAI/WCAG21/Understanding/conformance#accessibility-
> supported-definition
>
> The definition does not require that the Web content technology is
> supported by ALL user agents as long as it "is supported natively in
> widely-distributed user agents". In fact it goes further and says "The
> Accessibility Guidelines Working Group and the W3C do not specify
> which or how much support by assistive technologies there must be for
> a particular use of a Web technology in order for it to be classified
> as accessibility supported."
>
> By contrast, if you are doing an "accessibility review" or "assistive
> technology testing", then you should indeed report that the input
> type="date" element is difficult or impossible to use with Voiceover
> and Dragon.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Graham Armfield
> Sent: 25 September 2021 11:12
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers
>
> Wolfgang said...
>
>
>
> *2. Can we blame problems resulting out of bad behavior of browser or
> AT?a) If elements and attributes of HTML, CSS or ARIA are used
> according to the spec, can this ever be considered as failure in an
> *audit*?*
>
> I think this is a very good question. And in some ways we do have to
> take some view on this when reviewing websites for accessibility.
>
> One example would be the use of input type="date". This input type has
> been in the HTML5 spec for a good few years now, and in many browsers,
> with many ATs it can provide a fully accessible way of allowing users
> to select a date
> - including a date picker.
>
> But I believe that it's still not really supported in Safari on macOS,
> and it can be a difficult control to interact with when using Dragon
> NaturallySpeaking.
>
> There is an outstanding issue on Apple, but last time I looked there
> seemed to have been no movement. I also contacted Nuance about Dragon
> and they seemed less than interested.
>
> So, if we're reviewing or auditing a site that uses this date input,
> what's the best approach?
>
> Regards
> Graham Armfield
> Coolfields Consulting
>
>
>
> On Fri, 24 Sep 2021, 15:31 , < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Thanks Glen, a good list for reflection!
>>
>> 1. I just thought of adding 4.1.1 to detect bad behavior of browsers
>> and/or AT by testing with SR.
>>
>> E-g- I remember aria-errormessage to be hardly supported.
>> Would the usage despite support touch 4.1.1?
>>
>> 2. Can we blame problems resulting out of bad behavior of browser or AT?
>>
>> a) If elements and attributes of HTML, CSS or ARIA are used according
>> to the spec, can this ever be considered as failure in an *audit*?
>>
>> b) To which degree do we have to respect bad behavior in a
>> *development process"?
>>
>> Wolfgang
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf
>> Of Steve Green
>> Sent: Thursday, September 23, 2021 6:01 PM
>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers
>>
>> While agreeing with Glen, I would take a slightly harder line. The
>> WCAG success criteria do not mention the behaviour with screen
>> readers or any other assistive technology. You do not need to use any
>> assistive technologies at all when doing a WCAG audit. In just about
>> every case, your pass / fail decision MUST be based on manual
>> inspection of the code and user interface. Tools and assistive
>> technologies can provide useful support, but they are often wrong or
>> misleading.
>>
>> Some time ago, I went through all the WCAG success criteria to
>> determine which ones need to be tested with more than one browser.
>> Glen has already mentioned some for which that would not be necessary.
>> I reckon that of the
>> 50 level AA success criteria, only these 7 need to be tested with
>> multiple browsers as a matter of routine:
>>
>> SC 2.1.1: Keyboard Navigation (level A) SC 2.1.2: No Keyboard Trap
>> (level A) SC 2.4.1: Bypass Blocks (level A) SC 2.4.3: Focus Order
>> (level A) SC 1.4.4: Resize Text (level AA) SC 1.4.10: Reflow (level
>> AA) SC 1.4.11: Non-text Contrast (level AA)
>>
>> Depending on how the website is coded, it may be necessary to test
>> other success criteria with multiple browsers. That's usually an
>> indication that the code is pretty horrid.
>>
>> It might even be safe to drop SC 2.4.1 (Bypass Blocks) from that list.
>> Some browsers used to scroll the page but not move the focus position
>> when in-page links were operated, but I don't know if that is still true.
>>
>> I don't recall getting different results from different browsers with
>> any of the other 43 success criteria, so I would be very interested
>> to hear if anyone else has. Even if there are a few more, anyone who
>> is testing all 50 in multiple browsers is wasting an awful lot of time.
>>
>> Note that I am not arguing against testing with assistive technologies.
>> It's just that doing so constitutes an "accessibility test", which
>> can be anything you want it to be, not an audit for WCAG conformance,
>> which has a defined scope.
>>
>> Steve Green
>> Managing Director
>> Test Partners Ltd
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf
>> Of glen walker
>> Sent: 23 September 2021 16:06
>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers
>>
>> In theory, your application should work in every browser (firefox,
>> safari, chrome, edge, ie, opera) on every platform (mac, pc, mobile)
>> with every assistive technology (nvda, jaws, narrator, dragon,
>> switch,
>> talkback) at every CSS breakpoint.
>>
>> With unlimited budget and time, you could test every combination.
>> But for practical reasons, the testing is usually "limited" to a few
>> combinations (or even one combination in extreme cases). I say
>> "limited" but that's with respect to the various combinations. It's
>> not limited in how extensive the testing is regarding testing every
>> element on the page.
>>
>> More often than not, an accessibility issue that occurs with one
>> combination will also appear in a different combination. An image
>> missing alt text is going to be a problem no matter what browser
>> you're testing on. A list that is not semantic will be a problem no
>> matter what browser you're testing on. A table without headers is
>> going to be a problem no matter what browser you're testing on.
>>
>> There are, of course, minor differences between the various
>> combinations so sometimes you can find a problem with one that
>> doesn't exist on another.
>> For example, having something like "first name <input>" will show up
>> as a problem when testing with NVDA on both chrome and firefox but if
>> you test with JAWS, it reads ok on chrome (but not firefox). So if
>> you were only testing JAWS on chrome, you might miss the problem.
>> (This is why I usually look at the code too and not rely solely on a
>> screen reader to find issues. Even if a form reads ok, I typically
>> look at the html to see if the label is really associated with the
>> field.)
>>
>> Another difference between browsers is if you have a scrollable
>> container (overflow). When a container has a scrollbar, firefox
>> makes that container a tab stop but chrome does not. So now you have
>> a tab stop that potentially does not have a name or role. It could
>> be confusing for a screen reader user on firefox.
>>
>> I know this is all digressing a bit from your original question,
>> asking if you needed to test 1.4.12 in all browsers. The short
>> answer is "yes" - test everywhere, or at least as much as possible.
>>
>> In your particular case, I have not seen a problem with the Stylus
>> plugin
>> *not* applying to iframes. I *do* see the problem with the
>> bookmarklet not applying to iframes. So Stylus should work if you
>> want to test for 1.4.12. I edited my style and added the same code
>> that the bookmarklet
>> uses:
>>
>> * {
>> line-height: 1.5 !important;
>> letter-spacing: 0.12em !important;
>> word-spacing: 0.16em !important;
>> }
>> p{ margin-bottom: 2em !important;}
>>
>> When I viewed a page with an <iframe>, the styles were applied to the
>> iframe. You can test it with
>> https://www.w3schools.com/html/tryit.asp?filename=tryhtml_iframe_heig
>> h
>> t_width
>> .
>> It has 2 nested iframes.
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
> > > archives at http://webaim.org/discussion/archives
> >
> ------------------------------
>
> Subject: Digest Footer
>
> > > archives at http://webaim.org/discussion/archives
> >
>
> ------------------------------
>
> End of WebAIM-Forum Digest, Vol 198, Issue 18
> *********************************************
>


--

Thanks and Regards
Ramakrishnan