RE: Custom stylesheet question for LVTF

Hi Wilco,

From things that Wayne & Jon have said, and my own experimentation there are a few levels of customisation [1]:


  1.  Standard browser features (like zoom).

  2.  Within the authors styles, not aiming for layout changes.
e.g. underlining all links, over-riding focus styles. Mostly works at the moment.

  3.  Overriding layout styles, e.g. linearise everything except tables.
Very problematic, you generally have to ignore author styles and start again. Often get weird script issues and lots of unwanted content.

  4.  Author supplied customisation options. E.g. site based colour scheme changers, or the COGA examples from 2.1 (see my article for a screenshot from then). Whether the site provides the control or it is browser based doesn’t matter too much, the author has to do the work to create the variations.

I’m sure there are lots of different cases around levels 2 & 3, but those are examples I’ve seen people using.

So I think level 2 is currently still useful, and it isn’t just stylus. I’d include high-contrast mode and some dyslexia plugins (changing colours & fonts) at that level as well.

But as soon as you start over-riding layout it tends to become unusable very quickly, without an obvious solution.

Cheers,

-Alastair

1] https://alastairc.ac/2017/02/four-levels-of-accessibility-customisation/



From: Wilco Fiers <wilco.fiers@deque.com>
Sent: 29 April 2020 12:05
To: Jonathan Avila <jon.avila@levelaccess.com>
Cc: Jim Allan <jimallan@tsbvi.edu>; public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>
Subject: Re: Custom stylesheet question for LVTF

Hey Jon,

Thanks for the input. How would you think this related to the requirements of success criterion 1.3.1? Because if it's impractical to write custom stylesheets that work anywhere, then does 1.3.1 even matter for custom stylesheets? If you need to write a new stylesheet for every site you want to have it used on, you don't need that site to use semantic markup. You can just make your custom styles based on whatever classes or IDs or whatever else they are using.

If "universal" stylesheets are no longer viable, then that puts custom stylesheets outside the reach of most people (anyone who doesn't know how to write them, basically). Is that correct?

W


On Fri, Apr 24, 2020 at 5:58 PM Jonathan Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>> wrote:
My quick thought is that example is workable although requires some extra effort.  It’s certainly a possibility that users with low vision might change list styles or even heading styles beyond just size, colors, spacing, but also with some marker such as via pseudo content ore list style type.

What I find personally more problematic is the ability to create CSS that actually overrides what needs to be override without overriding everything.  That is for me – I just need some enhancements to contrast, focus indicator, affordance, etc. without blowing away the whole visual appearance and ending up with something that looks totally different.   Since most browsers like Chrome don’t allow for user style sheets any styles added via Stylus for example are at the page level and certain sectors such as ids take precedence over others.  This makes actually changing text in rich editors and other situations very difficult.     Changing the color of some text to be darker such as text on a light background while not making text darker that is on a dark background is an issue.  Even for people who are knowledgeable about CSS implementing these often requires site specific style modification and time – it’s not easy and also not available on mobile devices.

Jonathan

From: Jim Allan <jimallan@tsbvi.edu<mailto:jimallan@tsbvi.edu>>
Sent: Wednesday, April 22, 2020 1:20 PM
To: public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org<mailto:public-low-vision-a11y-tf@w3.org>>; Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>>
Subject: Fwd: Custom stylesheet question for LVTF

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.

Hi LVTF,
We have a request for thoughts.
let's respond to the list.

Jim


---------- Forwarded message ---------
From: Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>>
Date: Thu, Apr 16, 2020 at 4:48 AM
Subject: Custom stylesheet question for LVTF
To: <jimallan@tsbvi.edu<mailto:jimallan@tsbvi.edu>>

Hey Jim,

The ACT-Rules community group had a question we wanted to get input on from the LVTF, I wasn't sure what channel to use to communicate. Please let me know if I need to go somewhere else for this.

The question is about custom stylesheets and as to whether or not code like this is a problem:

<div role="list">
  <li>Some content</li>
</div>


WCAG is a little vague on what should and shouldn't be expected from someone using custom stylesheets. I know tools like Stylish are relatively popular still to tweak the styles of a website, but it's pretty complicated to write a good custom stylesheet, especially if you want to make a robust one, which is where the above example comes in.

So our question breaks down into two;

1. How important does LVTF think custom stylesheets are, given how complex things have gotten To what extent does LVTF think page styles need to be configurable? How far does 1.3.1 go? I would expect it to include things like allowing changes at the element level, like tweaking font size, color, borders, spacing, etc. But what about more complex things like changing the layout of a menu, or to customise the style of a list?

2. What level of effort is reasonable to expect from someone using a custom stylesheet? If I with my custom stylesheet want to make sure all lists are marked up a certain way, is it reasonable to expect all lists to follow the HTML spec, or should the author of the custom stylesheet be expected to create a robust custom stylesheet which tries to anticipate odd uses of ul, ol and li elements?


For the example above, where ARIA is used in combination with a native HTML element, this is a programatically determined relationship, but it's invalid HTML; li elements must be contained in a ul, ol or menu element. I suspect this passes SC 1.3.1, but I don't think it is particularly reasonable to expect the author of a custom stylesheet to anticipate all the odd ways ARIA can interact with native elements.


So, long story, sorry about that, but it's a complicated question. I hope my explanation of it is clear enough. Please do ask if this needs further elaboration, or if I need to send this somewhere else.

Thanks for our time,

--
Wilco Fiers
Axe for Web product owner - Co-facilitator WCAG-ACT - Chair ACT-R


--
TSBVI Need assistance? Click this link for help: MOJO HELP DESK<https://tsbvi.mojohelpdesk.com/mytickets/create#/ticket-form-selection>

Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9452 http://www.tsbvi.edu/

"We shape our tools and thereafter our tools shape us." McLuhan, 1964


--
Wilco Fiers
Axe for Web product owner - Co-facilitator WCAG-ACT - Chair ACT-R
[cid:BCBD7D4B-677E-4B95-AE3F-60005DBD9EE4]