ACTION-2005: Review media queries level 4 https://www.w3.org/tr/mediaqueries-4/

There are two groups of issues noted below. The first group are issues with capabilities of Media Queries 4. The second group are SVG images.

Issues with capabilities - I wonder whether we want to enable personalization via media queries and provide setters for things that could affect accessibility to the UI behavior is customized for the user.

1. We want a high contrast media query. This is of general value to authors for icons, charts, styled sections, custom controls... This is of great interest to DPUB which has lots of use cases.

In the document, high contrast media feature is mention here -
Issue 2 Using this media feature for accessibility purposes overlaps a lot with the high-contrast media feature proposed by Microsoft. Can we adjust this so that it covers all use cases for both, or somehow modify them to work in an orthogonal, rather than overlapping, fashion?

2. Pointer - For accessibility we might want an API (setter) to tell the user agent which option should be returned for the user based on their needs or preferences - ie return none regardless of the platform capability.
Sec 7.1 Pointer User agent can return none, coarse or fine for pointer.

3. Hover - For accessibility we might want an API (setter) to tell the user agent which option should be returned - ie return none regardless of the platform capability.
Sec 7.2 Hover User agent can return none, on-demand or hover.

4. Light-level - For accessibility purposes, user agents may offer manual controls allowing the user to switch between the 3 levels of independently of the ambient light level, as high contrast or low contrast styles may be more suitable for users with visual disabilities. We have an interest in how this plays out.
Sec 8.1 light-level

Syntax diagrams are not accessible. Should the diagrams all be figures with a figcaption? Here is my first cut - it proposes two alternatives A and B. I plan on getting feedback from the SVG accessibility task force, but feel to wordsmith/propose alternatives on list.

For the captions I preferred the term 'syntax diagram'. However, in section 3 the diagrams are referred to as 'railroad diagrams' - both the text in section 3 and the suggested text below should use the same term.

ec 2. svg railroad diagram needs to be accessible or needs text equivalent.
A. syntax diagram of media query described in this section.
B. syntax diagram main route goes through a <em>media condition</em> alterate route may have either an <em>only</em>, <em>not</em> or no modifier and then goes through a <em>media type</em> then route either goes through an empty branch or a branch with <em>and</em> and an <em>media condition</em>

Sec 2.1 svg railroad diagram needs to be accessible or needs text equivalent.
A. syntax diagram of comma-separted media query list.
B. syntax diagram: main route goes through a <em>media query</em>, alternate empty branch, alternate main route with a <em>comma</em> in a loop

Sec 2.4 svg railroad diagram needs to be accessible or needs text equivalent.
A. syntax diagram showing three forms of media feature: a feature name with a value, only a feature name or a range form.
B. syntax diagram: three routes available, route 1 has a <em>feature name</em> <em>:</em> <em>feature value</em>, route 2 has (only) a <em>feature name</em>, route 3 has a <em>range form</em>

Sec 2.4.3 svg railroad diagram needs to be accessible or needs text equivalent.
A. syntax diagram showing range forms. there are two range forms one has a pair of feature name/values separated by one of the following operators (= < <= > >=). The second form has a value operator feature name operator value. There are two flavors of the second form one flavor uses either < or <= operators and the other flavor use either > or >= operators.
B. syntax diagram: three main routes, the first route goes through a <em>feature name/value</em> then it has a branch for each of the operators <em>=</em> <em><</em> <em><=</em> <em>></em> <em>>=</em> that rejoin then goes through a second <em>feature name/value</em>. The second route goes through a <em>value</em> and branches for each operator <em><</em> and <em><=</em> rejoining then <em>feature name</em> and branches for each operator <em><</em> and <em><=</em> and rejoining for the second <em>value</em>. The third route goes through a <em>value</em> and branches for each operator <em>></em> and <em>>=</em> rejoining then <em>feature name</em> and branches for each operator <em>></em> and <em>>=</em> and rejoining for the second <em>value</em>.

Adding link to forwarded message from Florian. https://lists.w3.org/Archives/Public/public-apa/2016Feb/0030.html

last two paragraphs from Florian's email

There are some areas where preference media queries may have a role to play, and the CSSWG is interested in looking into these even though they have not been prioritized so far. This would be focused on accessibility, tying into the OS level controls that already exist. Examples put forward by apple have included: preferring reduced animation, preferring using shapes rather than colors to draw distinctions between things, or preferring reduced transparency.

The difficulty is that these things need to be fairly abstract (if they were not, user style sheets would be more appropriate), yet actionable, and at the same time be a sufficiently short list that implementors and authors can be expected to care. The most likely path forward here is to work from the list of settings that pre-exist in operating systems and standardize that.