WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Testing SC 1.4.12 in multiple browsers

for

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

From: Ramakrishnan Subramanian
Date: Wed, Sep 22 2021 11:03PM
Subject: Testing SC 1.4.12 in multiple browsers
No previous message | Next message →

Hi,
In One of the applications, the text spacing bookmarklet which we use
does not seem to work may be because of the multiple layers of frames
within the main iframe in the page. Hence, we tried with the stylus
browser extension which does not seem to support IE 11 in Windows and
Safari in Mac. Hence, I have the following query.
In case where we support multiple browsers in both Windows and Mac
platforms, is it necessary to test against the WCAG 2.1 SC (1.4.12
text spacing) in each browser and platform combination we support? If
yes, is there any reliable test tool which can be used in various
OS/browser combinations?
FYI, we use the following bookmarklet.
https://codepen.io/stevef/full/YLMqbo


--

Thanks and Regards
Ramakrishnan

From: Patrick H. Lauke
Date: Thu, Sep 23 2021 5:13AM
Subject: Re: Testing SC 1.4.12 in multiple browsers
← Previous message | Next message →

On 23/09/2021 06:03, Ramakrishnan Subramanian wrote:
> Hi,
> In One of the applications, the text spacing bookmarklet which we use
> does not seem to work may be because of the multiple layers of frames
> within the main iframe in the page. Hence, we tried with the stylus
> browser extension which does not seem to support IE 11 in Windows and
> Safari in Mac. Hence, I have the following query.
> In case where we support multiple browsers in both Windows and Mac
> platforms, is it necessary to test against the WCAG 2.1 SC (1.4.12
> text spacing) in each browser and platform combination we support? If
> yes, is there any reliable test tool which can be used in various
> OS/browser combinations?
> FYI, we use the following bookmarklet.
> https://codepen.io/stevef/full/YLMqbo

Reiterating that the point of 1.4.12 isn't "when I use this particular
bookmarklet or extension, does the text spacing change?"

It's more *if* the user manages to change the text spacing metrics, does
the site handle it properly.

See https://github.com/w3c/wcag/pull/1687

P
--
Patrick H. Lauke

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

From: glen walker
Date: Thu, Sep 23 2021 9:05AM
Subject: Re: Testing SC 1.4.12 in multiple browsers
← Previous message | Next message →

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.

From: Steve Green
Date: Thu, Sep 23 2021 10:00AM
Subject: Re: Testing SC 1.4.12 in multiple browsers
← Previous message | Next message →

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.

From: glen walker
Date: Thu, Sep 23 2021 10:27AM
Subject: Re: Testing SC 1.4.12 in multiple browsers
← Previous message | Next message →

I would go with what Steve says and ignore what I said :-)

I use AT to find a11y issues. It's easy to listen to elements with a
screen reader as I tab through the page. If I hear something that doesn't
match what I see, it raises a flag. Likewise, if I navigate with the
screen reader's table navigation or list navigation or heading navigation
(or use the SR dialog to display a list of tables, lists, or headings), if
I don't move to elements that appear to be tables, lists, or headings, that
raises a flag. But that does *not* mean if it reads correctly that there
isn't a problem. I always go back to code inspection, as Steve recommends.

Regarding 2.4.1, I would still test on multiple browsers. It used to be
that IE needed the target of the skip link to have tabindex="-1" whereas
chrome and firefox did not. (Not sure about safari). If the page only
scrolls and doesn't move the focus, then I would consider the "mechanism"
broken and would fail 2.4.1.

From: Jonathan Avila
Date: Fri, Sep 24 2021 6:09AM
Subject: Re: Testing SC 1.4.12 in multiple browsers
← Previous message | Next message →

WCAG does require that criteria be met using accessibility supported methods. The support level depends on the technologies used to claim conformance. While there are many things that can be tested automatically - many incorrect implementations of custom controls and other misuse of ARIA are quickly and clearly shown by use of assistive technology such as screen readers. Not only can these breakages be quickly spotted compared to reading through the DOM but the demonstration of the issue quickly communicates the impact to actual users. Assistive technology cannot be relied upon solely for spotting issues but I find they are often quicker at detecting issues related to custom controls. For example, ability to use combo boxes, menus, etc. with incorrect implementations that work correctly with the keyboard/mouse visually but do not work with screen readers. Links that work with the keyboard and mouse but don't support programmatic activation, etc.

Jonathan

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: Thursday, September 23, 2021 12:01 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


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.

From: wolfgang.berndorfer@zweiterblick.at
Date: Fri, Sep 24 2021 8:31AM
Subject: Re: Testing SC 1.4.12 in multiple browsers
← Previous message | Next message →

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.

From: Graham Armfield
Date: Sat, Sep 25 2021 4:11AM
Subject: Re: Testing SC 1.4.12 in multiple browsers
← Previous message | Next message →

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

From: Steve Green
Date: Sat, Sep 25 2021 7:25AM
Subject: Re: Testing SC 1.4.12 in multiple browsers
← Previous message | No next message

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