[TC4R Symposium] Limitations of user CSS

Thanks Shawn for letting me know about this symposium.  I'm the
author of the low-vision CSS generator at http://people.ds.cam.ac.uk/ssb22/css/
mentioned in your paper http://www.w3.org/WAI/RD/2012/text-customization/r14

I'd like to add a few comments about what I have been unable to
achieve due to the limitations of user CSS, in the hope that
someone can figure out how to fix this situation.

Six things I have NOT been able to do:

1.  Support sites whose Javascript makes assumptions about the
positioning of page elements.  Some "high end" sites rely on
extremely complex, positioning-dependent Javascript that simply
breaks when a user CSS is applied.  I have several times been
locked out of my bank account due to attempting to use my user
CSS with online banking - their malfunctioning Javascript
triggered a security alert and locked me out permanently, so I
had to go to my branch with two forms of identity to reactivate
my account.  (And this is a large UK bank.)  Several other sites
can be unusable with user CSS, and when using these sites it is
necessary to turn off user CSS and struggle without it.

I wish there was a way to trick the Javascript into thinking
that the elements are displayed as the site programmer expects,
whereas in actual fact they are displayed differently.  That way
we can avoid crashing any badly-written Javascript that has not
been tested in large print.  I.e. can we have:

     Javascript <---> DOM and author CSS ---> user CSS ---> display

i.e. the Javascript interacts with the DOM and author CSS as
before (the double arrow), but it has no knowledge of the fact
that user CSS changes everything before it's displayed (the
single arrows).  This separation will have to be switchable
because most Javascript DOES behave well under user CSS and in
some cases a script might respond in a positive way to knowledge
of the actual display, but it would be nice to be able to hide
this as a strategy for coping with badly-written scripts.

Perhaps it's possible to put a 'hack' into the CSS standard
whereby a user CSS can say "apply the following rules in a
'script-invisible' way".  Alternatively, it would be nice to
implement a browser with a "hidden display" (with no user CSS)
and a method for copying the information out of the hidden display
onto a real display (with user CSS).  The Firefox test framework
"Selenium" could possibly be a starting point for this.  The hardest
part would be translating all the keyboard and mouse events from the
real display back onto the hidden display for its scripts to handle.

   Thankfully, it's quite rare that a site is totally unusable
   with user CSS - most sites work OK with it.  But when it does
   happen, it's really annoying.  Memo to large companies: please
   get your testing team to actually TEST the site in at least
   one giant-print CSS and preferably two or three.  And by "test"
   I mean actually go through the use cases, not just look at the
   front page.

2.  Support sites that severely blur the separation between
style and content.  Site developers need to be reminded that a
user CSS might override any and all rules of the site's CSS. 
Indeed, a generic user CSS (one written for all sites, not just
a specific one) MUST err on the side of overriding more, in
order to keep things consistent - for example, because large
print makes all the elements bigger, an author's fixed element
sizes have to go, which means ALL author element sizes have to
go (because there's no way for a user CSS to say "I only want
this rule if the author's stylesheet does not meet criteria X"
for any X), and ALL author positioning rules have to go for similar
reasons.  However, an increasing number of websites are RELYING
on the author css's positioning information for parts of their
interaction.  A user clicks a link, and, instead of being taken
to a new page, some Javascript on the existing page tries to
move some boxes around using CSS.  But because of the user CSS
needing to contain so many "disable all these author rules" overrides,
the effect is not at all what the developer had in mind.

  For example, if you shop on eBay and click "Buy it now", what
  happens (after their recent change) is a new box appears, which
  is supposed to be positioned in front of you but with a user CSS
  may end up being added to the end of the document, and if you
  don't scroll down and find it then it looks like nothing happened.

  I do try to add site-specific rules to cope with some of these
  cases, but I have not yet done it for eBay because I have not
  yet figured out what the rule should be.  It doesn't help that
  these sites put out seemingly obfuscated HTML/CSS/Javascript code
  - in some cases it can take me ages to come up with the right hack
  (and then it'll only last until they change the site again).
  For this reason I tend to add site-specific rules only as an
  occasional last resort - I don't like having to constantly
  "battle" with every web designer in the world.

  The CSS standard could be enhanced to address this problem. 
  Currently, CSS selectors apply only to elements and attributes
  in the HTML document.  I wish there were a way of selecting
  elements based on author CSS rules as well.  For example, I'd
  like to say "select all elements whose author style matches
  pattern X, and change their style as follows".

  This can possibly be done with user Javascript, but user
  Javascript is much less efficient than user CSS; it would have
  to keep polling and updating the page, and it would make everything
  run slowly and probably take some time to fix the appearance.
  I have several times thought about starting a project to fix
  the appearance of pages using user Javascript instead of user CSS
  but I've always been put off by the sheer complexity of what I
  want to achieve and how slowly it would probably run.

3.  Reducing the need for horizontal scrolling in wide table-based
layouts.  It can be hard for the user CSS to ensure that cells
containing paragraphs of text are no wider than the viewport.
(Very early versions of Mozilla tended to lay out tables more
helpfully than modern browsers.  I once raised a feature request
to make the old behaviour an option, but my request doesn't seem
to be in their database anymore.)

4.  Allow a browser's "find in page" feature to search the ALT
text of images.  Many "high end" sites have fancy-looking images
for some of their navigation buttons, and they do provide ALT text
but this ALT text is not accessible from a graphical browser.
If the entire page is in giant print, then it will naturally take
many many screenfuls, and the user might need to use a search
function more frequently, rather than just looking with the eyes.
The most annoying thing about text as images (besides the fact
that it's harder to customise the appearance of images) is that
you can't search for it, even if there's an ALT tag.
I managed to persuade a UK supermarket to label their checkout
buttons with searchable text that says "checkout buttons", and
that was helpful, but there are many other instances of this.
Another issue with it is that if it's not your native language
then you might want to use dictionary software to check the meaning
of a word; this cannot be done if the text is an image (unless
your dictionary software has OCR capabilities, but even then the
OCR might have trouble with some of the fancy fonts sites use).

5.  Customisation of the "pop-up" text that can appear with the
TITLE= attribute.  It is not always possible to customise this
at the operating system level.  Also it would be nice to ensure
that pop-ups are positioned entirely over the browser window and
not elsewhere.  This is because, if a screen magnifier is in use
for the entire desktop, the user's "full screen" may be only a
small fraction of the desktop.  A user might have sized and
positioned a browser window to fill the part of the desktop that
corresponds to "full screen", but the browser is not aware that
the user cannot see the rest of the desktop.  If that browser
then pops up tooltip text that is not entirely over its own window,
it will be necessary for the user to scroll the entire desktop in
order to see the whole tooltip.  Further, scrolling the desktop
usually means moving the mouse, which means the tooltip goes away;
you have to first of all carefully position the desktop such that
the position you think the tooltip will appear is visible, and
then try to get the tooltip again and hope it will be positioned
the same as before (sometimes it is not).  More user control over
tooltip positioning would be helpful.

6.  Allow user style sheets to be switched with one click.  I
have yet to see a browser that does not bury the user CSS
settings deep within the advanced options dialogs, and
sometimes you even have to edit configuration files and restart
the browser for the changes to take effect.  That means if you
use several user stylesheets, or if you sometimes need to
temporarily switch off your user stylesheets for a problem site,
you either have a lot of work on your hands or else you need to
keep an array of alternative Web browsers all configured differently
(and the latter is not an ideal solution because all those
browsers don't share their bookmarks, history, passwords etc).

  I realise that user stylesheets may be an advanced function
  that you don't want to put in everybody's face, but once we
  have established that the user is advanced enough to want a
  user stylesheet (all users with reading difficulties have to
  be "advanced" I'm afraid), it would be nice for these users if
  a one-click control can be "turned on" in the interface.

  In the case of Firefox, I have managed to write a script that
  terminates the browser, changes the stylesheet, and restarts
  the browser; the user then needs to go through the "browser
  crashed" dialog and click to restore the session.
  I have not published this on my CSS page, because I don't want
  to make it obvious to web developers that we users are sometimes
  willing to turn off user CSS - they might take that idea as a
  license to ignore the issue.  In fact turning off user CSS is a
  negative experience and should be left as a last resort; it's
  certainly not for sites that want to be used for a long time.
  But it would be nice if browsers had more support for quick
  switching when necessary.

  Safari on Mac OS X deserves a special mention because it does
  at least let you keep the advanced settings dialog open in the
  background while you're browsing.  It's a pity it can only
  remember ONE recently-used user css though; others have to be
  found in the file selector.

Thanks.

Silas

-- 
Silas S Brown http://people.ds.cam.ac.uk/ssb22

Received on Thursday, 8 November 2012 18:40:30 UTC