Viewport rendering customization about silver HOT 4 CLOSED

Hi @slauriat Hi Shawn, I just wanted to toss out some ideas on the subject of reflow.

The keystone of responsive design is the media query, so what about an accessibility oriented query that can be used inside a media query (or on its own) to enable better responsiveness for accessible purposes?

This might be a little half-baked at the moment, but something like:

access query example

@media (min-width: 600) and (max-width: 799.99px) {
    
    body { 
        font-size: 14px; 
        color: #456;
        background:  #EFF;
        }
    h1 { font-size: 36px; }
    .wrapper {
        display: block;
        min-width: 500px;
        border: 1px solid #900;
        }

/***** access query — user agent wants content font set 2X bigger — this switches the .wrapper to flex box from block to allow better reflow, etc.  */

    @access (access-size-factor: large ) {
        body { font-size: 30px; }
        h1 { font-size: 38px; }
        .wrapper {
            display: flex;
            min-width: 600px;
            border-width: 2px;
            }
        }
        
/***** access query — user agent wants at least 50% more contrast and inverted polarity */

    @access (access-contrast: high) and (access-polarity: dark) {
        body { 
            color: #DEF !important;
            background:  #111 !important;
            }
        .wrapper {
            border-width: 4px;
            border-color: #F55;
            }
        }
    }

So, implied above are "accessibility properties" that a user could set in their browser to trigger specific content/CSS adjustments.

access-contrast: low, normal, high, max, dynamic
access-focus: normal, enhanced, sticky
access-polarity: dark, light, dynamic (relative to background)

access-size: small, normal, large, giant
access-size-method: proportional, linear, user-relative
access-size-spacing: tight, normal, loose, large, dynamic

The main idea is giving authors more control on presentation — with a setup like this, one layout that might break easily and/or be too complicated for accessible needs, then another simplified and also more flexible layout that won't break on zoom, is easier to navigate, but yet will still retain much of the author's original style/intent.

from silver.

Although I fully support personalisation and would love to work on solution (in near future) this seems like a question for CSS, not WCAG / Silver. (we can have a chat with the CSS folks of course).

From my gut feeling I don't see this as a valid way to go, CSS already has enough potential the default way and accessibility oriented queries can not be defined as user needs are so diverse so how do you know what is needed.

Also the settings local in the UA might be an issue, a 'in the cloud' solution would be great...

Also I don't see this happen for developers / designers as the 'default' fix to become accessible is already hard as it is.

From a privacy perspective this will probably also get some push back the same way AT sniffing is not wanted.

from silver.

Hi @jake-abma

Although I fully support personalisation and would love to work on solution (in near future) this seems like a question for CSS, not WCAG / Silver. (we can have a chat with the CSS folks of course).

Yes, it is CSS — current accessibility & perception research is currently "finding" a lot of things that are (or could be) parts of non-author technologies — Silver has a much more open scope than WCAG, partly to help address or liaison between the various "worlds" as I understand it.

From my gut feeling I don't see this as a valid way to go, CSS already has enough potential the default way and accessibility oriented queries can not be defined as user needs are so diverse so how do you know what is needed.

One of the mandates of silver is specifically to start with user needs and then build everything From that premise … As I mentioned, I was just floating this out as a initial idea, It may not have merit. Nevertheless user needs are indeed diverse, but that doesn't mean they can't be categorized.

Also the settings local in the UA might be an issue, a 'in the cloud' solution would be great...

There are some other parts to this overall concept in the works relative to some other research that would make it a more complete solution. The fact that cloud computing is common makes some of this more workable, Such as portable yet private user profiles of needs stored in a secure cloud.

Also I don't see this happen for developers / designers as the 'default' fix to become accessible is already hard as it is.

Yes, hard — but a big part of "what is hard" is designing a functional site that meets client needs, plus meets aesthetic design objectives... and is also capable of achieving everything needed in terms of accessibility. All at once. By having an "@access query", a design can be completed and then handed off to an accessibility work group (or work in tandem with) who can then focus on addressing & accommodating needs without interfering with an otherwise working design. Similarly, it would make it easier for accessibility teams to modify existing sites.

For instance, let's say the site has a complicated but functional multi-leel menu, that most users like for the content — but a functional need for some cognitive issues may indicate the need for a simplified menu structure. @access query would allow such a diverse site development, just as responsive query provides a different menu structure and type for mobile vs desktop.

In programming, class libraries and object oriented concepts allows large independant teams to work on an app effectively. Similarly, @access queries would allow separate teams to work on/develop the accessibly aspects of a site design with a level of independence — AQ then is as much a development workflow tool as it is a user profile connection tool.

From a privacy perspective this will probably also get some push back the same way AT sniffing is not wanted.

Yes, definitely privacy is a concern which is why privately stored user-needs profiles and @access query is ideal — it is all parsed client side, in theory requiring no involvement from the server — yes, sure javascript might be used to track certain states/query levels, but that is already a separate privacy issue unrelated to accessibility.

from silver.

Will be relevant in a future draft. Closing for now.

from silver.