Multiple Examples: contrast and IE11 compatibility bugs

[JAWS-test]

Visually impaired users need sufficient contrast and partly "High Contrast Mode" of the operating system. I have checked all examples and found some errors with contrast and "High Contrast Mode". If I have noticed any other errors, I will also list them in the following:

https://w3c.github.io/aria-practices/examples/accordion/accordion.html
Contrast arrow icon: 2.7:1
Contrast border 1.5:1

https://w3c.github.io/aria-practices/examples/dialog-modal/alertdialog.html
Does not work with IE 11 (button "Save", button "Yes")
"Saved" message is shown only for 3 seconds

https://w3c.github.io/aria-practices/examples/button/button.html
IE 11: Icon at "Mute" button not visible, state of the button not perceptible

https://w3c.github.io/aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html
If there is an element at the bottom of the browser, the list entries are not displayed.

https://w3c.github.io/aria-practices/examples/combobox/aria1.0pattern/combobox-autocomplete-both.html and the two other aria 1.0 combobox pattern
IE 11: List entries not visible

https://w3c.github.io/aria-practices/examples/dialog-modal/datepicker-dialog.html
Does not work with IE 11
Contrast date picker icon: 2.3:1

https://w3c.github.io/aria-practices/examples/disclosure/disclosure-img-long-description.html,
https://w3c.github.io/aria-practices/examples/disclosure/disclosure-faq.html,
https://w3c.github.io/aria-practices/examples/menubar/menubar-1/menubar-1.html,
https://w3c.github.io/aria-practices/examples/menubar/menubar-2/menubar-2.html,
https://w3c.github.io/aria-practices/examples/treeview/treeview-2/treeview-2b.html
transparent image for status: not or poorly visible in high contrast mode

https://w3c.github.io/aria-practices/examples/grid/LayoutGrids.html
Example 2: Does not work with IE 11
Example 2: Contrast delete icon: 1.6:1

https://w3c.github.io/aria-practices/examples/grid/dataGrids.html
Example 2: sort icon not correct visible in high contrast mode
Example 2: pen icon not visible in high contrast mode (background image)

http://www.w3.org/TR/wai-aria-practices-1.1/examples/listbox/listbox-rearrangeable.html
Example 1: button "Not Important" does not work with IE 11
Example 1: arrow icon not visible in high contrast mode (background image)
Example 2: buttons "Add" and "Remove" do not work with IE 11

http://www.w3.org/TR/wai-aria-practices-1.1/examples/listbox/listbox-collapsible.html
arrow icon not correct visible in high contrast mode

http://www.w3.org/TR/wai-aria-practices-1.1/examples/listbox/listbox-scrollable.html,
http://www.w3.org/TR/wai-aria-practices-1.1/examples/listbox/listbox-collapsible.html
Firefox: List entries are not displayed in the visible area

https://w3c.github.io/aria-practices/examples/menu-button/menu-button-actions.html
Missing border around the list entries (important in high contrast mode)
List entries are not displayed in the visible area

https://w3c.github.io/aria-practices/examples/slider/multithumb-slider.html
handle not or poorly visible in high contrast mode (transparent image)

https://w3c.github.io/aria-practices/examples/spinbutton/datepicker-spinbuttons.html
arrow icons not or poorly visible in high contrast mode (transparent image)
High contrast mode: not recognizable, which date was selected, because all 3 dates look identical

https://w3c.github.io/aria-practices/examples/toolbar/toolbar.html
arrow icons not or poorly visible in high contrast mode (transparent image)
High contrast mode: pressed buttons not perceptible, because they are all displayed with the same border

https://w3c.github.io/aria-practices/examples/treeview/treeview-1/treeview-1a.html
High contrast mode: Borders of the entries overlap text of nested entries
type icons not or poorly visible in high contrast mode (transparent image)

https://w3c.github.io/aria-practices/examples/treegrid/treegrid-1.html
arrow icons not visible in high contrast mode (background images)

[mcking65]

@JAWS-test, thank you for this thorough review! This is very helpful.

[ZoeBijl]

I’ll fix the colour contrast issues. But I won’t fix any of the IE11 issues.

[JAWS-test]

If IE 11 problems are generally not resolved, the following sentence in the chapter Browser and Assistive Technology Support may need to be adjusted:

Similarly, JavaScript and CSS in this guide is written to be compatible with the most recent version of Chrome, Firefox, Internet Explorer, and Safari at the time of writing. In particular, some JavaScript and CSS may not function correctly in Internet Explorer version 10 or earlier.

[ZoeBijl]

Good point. Will discuss.

Colour contrast issues

• Accordion arrow icon (will be fixed by Accordion Example: Correct color contrast (Issue #1132) #1200)
• Accordion border (will be fixed by Accordion Example: Correct color contrast (Issue #1132) #1200)
• Date picker (fixed by Datepicker Example: Increase colour contrast ratio to pass WCAG (#1170) #1172)
• Layout Grid delete button

High Contrast Mode

• Disclosure: transparent image for status: not or poorly visible
• Menubar: transparent image for status: not or poorly visible
• Treeview: transparent image for status: not or poorly visible
• Data grid: pen and sort icons not/barely visible
• Listbox: arrow icon not visible
• Menubutton: Missing border around the list entries
• Slider: handle not or poorly visible
• Date picker: arrow icons not or poorly visible
• Date picker: not recognizable, which date was selected, because all 3 dates look identical
• Date Picker: The calendar icon button's focus isn't visible in HCM, because the border color is the only change (both transparent and colored borders show up the same in HCM)
• Date Picker: The currently selected day isn't visible in HCM
• Date Picker: The focus style for the currently focused day (.dateButton:focus) is very hard to perceive in HCM
• Toolbar: arrow icons not or poorly visible
• Toolbar: pressed buttons not perceptible, because they are all displayed with the same border
• Treeview: Borders of the entries overlap text of nested entries
• Treeview: type icons not or poorly visible
• Treegrid: arrow icons not

IE11

• Alertdialog doesn’t work?
• Button mute icon invisible
• ARIA 1.0 combobox’ list entries are invisible
• Date picker doesn’t work?
• Layout Grid doesn’t work?
• Listbox: “not important”, “add”, and “remove” button’s don’t work
• Menubutton: List entries are not displayed in the visible area

Firefox

• Listbox: List entries are not displayed in the visible area

@JAWS-test can you tell me:

• which OS version and browser you used to test the high contrast issues
• which Firefox version you used for the Firefox issue
• a few issues are listed as “doesn’t work”. Can you elaborate a bit on what you mean by “doesn’t work”? It would be helpful if we had a starting point. Like, what exactly is going wrong?

[JAWS-test]

which OS version and browser you used to test the high contrast issues

Windows 10, Windows 8, IE 11, Firefox

which Firefox version you used for the Firefox issue

The then current version of Firefox and Firefox ESR (August 2019). If there are any uncertainties I can check it again with the current version of Firefox. The current Firefox 60.9.0 ESR still has the problem (just checked)

a few issues are listed as “doesn’t work”. Can you elaborate a bit on what you mean by “doesn’t work”? It would be helpful if we had a starting point. Like, what exactly is going wrong?

This always refers to the fact that the function of the buttons cannot be triggered (probably due to JS errors). This applies to activation with mouse and keyboard. If desired, I can test this for each element again and describe it in detail. For example: At Date Picker Dialog Example I get a message on the console that IE 11 does not support the methods repeat and forEach. In fact, it is probably the easiest way to explain that IE 11 is not supported by APG.

[jnurthen]

Can we just create a polyfill bundle for the methods used which are not supported by IE11?

To me this would lead to easier to read code rather than having to change the implementation.

[ZoeBijl]

This always refers to the fact that the function of the buttons cannot be triggered (probably due to JS errors). If desired, I can test this for each element again and describe it in detail

If you could go ahead and do that for date picker and and layout grid that’d be great! Thank you.

[sh0ji]

Can we just create a polyfill bundle for the methods used which are not supported by IE11?

To me this would lead to easier to read code rather than having to change the implementation.

I like this but it seems like it would be hard to maintain. I imagine it might be easier (and more familiar to many devs) to include a build stage so that we can write modern JavaScript and CSS but deploy browser-compatible code.

Some combination of Babel (with @babel/preset-env), PostCSS (with postcss-preset-env), and Browserslist should do the trick.

[carmacleod]

I'll take "Disclosure, Menubar, Treeview: transparent image for status: not or poorly visible in high contrast mode".

I assume the problem image is the brown triangle, which is used in Disclosure and Treeview to show that they can be expanded/collapsed, and in Menubar to show that Menus can be dropped down. (I also assume that the brown dot for radio menu items is a problem, too).

I plan to fix this by using high contrast media queries to change the image color as described here:
https://css-tricks.com/accessible-svgs-high-contrast-mode/

Just mentioning the media query thing in case that helps fix any of the other high contrast problems.

[ZoeBijl]

I like this but it seems like it would be hard to maintain. I imagine it might be easier (and more familiar to many devs) to include a build stage so that we can write modern JavaScript and CSS but deploy browser-compatible code.

Some combination of Babel (with @babel/preset-env), PostCSS (with postcss-preset-env), and Browserslist should do the trick.

How would you see that work? Because if there’s one part of web development that annoys the heck out of me it’s build processes. Of course this wouldn’t necessarily impact the examples themselves. Just add more complexity to maintaining what is in essence static code.

[JAWS-test]

@carmacleod If I have seen this correctly, the procedure described at https://css-tricks.com/accessible-svgs-high-contrast-mode only works in IE and Edge. HCM should also be supported in Firefox. Therefore it would be better to use graphics without transparent background instead of graphics with transparent background or font icons (whose color is automatically adjusted).

[jnurthen]

... Or use an icon with 2 contrasting colours in it.
If the expand icon had a white border around the icon that would result in sufficient contrast in both dark and light high contrast modes

[JAWS-test]

Datepicker

IE 11: The Datepicker button (aria-label="Choose Date") to the right of the input field cannot be activated with the mouse or keyboard.

Layoutgrid, Example 2: Pill List For a List of Message Recipients

IE 11:

• The Add button to the right of the input field cannot be activated with the mouse or keyboard.
• Submitting entries with Enter is also not possible.
• The Delete buttons within the list entries can neither be activated with the mouse nor with the keyboard.

Cause: IE 11 does not support JS methods repeat, append and remove

[smhigley]

Re: contrast. I personally like using SVGs + currentColor, then setting the text color on the parent element to control the icon color. It doesn't require prefixed media queries or altering current and future SVG assets to add a contrasting border (though I do like having a border as well! I just think the ease of currentColor means more devs reading the spec might adopt it).

As an example, the SVG icon in this pen: https://jsfiddle.net/01rh43vd/show
renders like this in Windows high contrast mode:

[StommePoes]

Yup, I'm a currentColor fan, so long as SVGs have a single fill/stroke! With more than one colour I fall back to either a contrasted background or outline. I know MS is moving the high contrast detection stuff into general CSS, but if there's a simpler way to just make things work, I prefer those.

Thoughts on the datepicker:

IE 11: The Datepicker button (aria-label="Choose Date") to the right of the input field cannot be activated with the mouse or keyboard.

It occurs to me that... it would NOT occur to me that an arrow-represented button which looks like it would open a calendar/datepicker would be called "Choose Date" (thinking of speech recognition). I'd think of it as "Open [something]" (open calendar, open picker...).

[ZoeBijl]

+1 for currentColor where possible.

@StommePoes related issue: w3c/aria#1038

[carmacleod]

@smhigley @StommePoes @ZoeBijl Thank-you for suggesting/confirming "svg + currentColor". I was wondering what the nicest/simplest way to solve this was! I learn more about the web every day. 😄

I looked into media queries a bit, too, and as @StommePoes mentioned, CSS may someday have a media query called prefers-contrast, but it is still in the early stages of being defined, so probably not available for real any time soon. Presumably it could one day be used if someone wants to keep brown triangles for regular contrast, and only switch to currentColor if the user prefers contrast. For now, though, matching the triangle color to the text is a really good solution.

[StommePoes]

@carmacleod Melanie Richards from MSFT does have a talk about that tho if you're interested: https://github.com/melanierichards/talks/tree/master/2019/tpac-hc

[carmacleod]

Oooh - nice! Thanks, @StommePoes ! I'm reading through this right now.

[JAWS-test]

In fact, it is probably the easiest way to explain that IE 11 is not supported by APG.

My suggestion is probably not so good, as currently 11% of all screen reader users continue to work with IE 11 (and even 3.5% with older versions of IE), according to Screen Reader User Survey

[StommePoes]

@carmacleod

Presumably it could one day be used if someone wants to keep brown triangles for regular contrast, and only switch to currentColor if the user prefers contrast. For now, though, matching the triangle color to the text is a really good solution.

I had missed this the first time I read through-- remember you can always wrap a parent around your SVG, and set your desired colour on that parent, and then always have currentColor all the time (no detection of anything necessary).

<element style="color: #b00">blah blah blood text blah blah
    <span style="color: brown"><svg style="fill: currentColor">...</svg></span>
   blah blah blood text la la la
</element>

\o/

[a11ydoer]

@carmacleod Thanks for finding this issue!