1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

Accessible CSS - what do you think?

Discussion in 'CSS' started by tomasz86, Jun 11, 2016.

  1. #1
    Hello everyone.

    This is my first post on this forum but I have been lurking for some time now. I am personally a big fan of @deathshadow and his views on Web development, even though I do not always agree in 100% with him.
    I have created this small project:

    The reason behind it is my frustration with the modern Web where visual design takes precedence over accessible and user friendly content. I am not a professional web designer so my primary view is that of a user. And as a user I have seen way too many websites whose owners either do not care for or do not know anything about accessibility. Is using proper colour combinations and easily to distinguish link styling really that difficult? Even very basic accessibility concepts seem to be completely alien to those who keep creating such websites.

    At the moment I have just managed to collect several CSS rules that should improve overall experience. They are not always universal, and you are expected to modify them when needed, as in case when non-default background and text colours are used.

    I would just like to ask you for your opinions and suggestions. Please let me know if there are any issues or if anything else should be added. I myself am willing to keep improving and updating the project for as long as I am able to.
    tomasz86, Jun 11, 2016 IP
    kk5st and sarahk like this.
  2. deathshadow

    deathshadow Acclaimed Member

    Likes Received:
    Best Answers:
    Trophy Points:
    Personally, I'm not a fan of having too much of the styling CSS static as a starting point. Every layout is too different for that and whilst there are some good sensible ideas, most of what you have is stuff I'd do unique every time.

    The lack of condensed properties also makes it larger than need be... and I am always hesitant to ever consider using !important as usually that just means there's something jacktarded with your inheritance and/or specificity. In fact, about the only time I use !important is in user.css client side to override the rubbish inaccessible train wrecks found on many sites and forums. (like Digitalpoint)

    For backwards compatibility sake I'd never use rgb on values with no alpha channel. Do the conversion, and I prefer to round to the nearest whole 16th per channel for the 3 digit hex versions. The latter part is personal preference, but the former is important if you still care about users coming from legacy browsers. (and I still support clients at places like hospitals who are running that "windows fundementals" edition that's a gutted XP without luna and a locked down copy of IE 6 on WYSE thin clients)

    You're also dicking around with the behavior of a whole bunch of elements like ABBR that shoudln't be common enough to waste code on, and really since I see SUMMARY and DETAILS as pointless HTML 5-tard code bloat bullshit, I probably wouldn't bother wasting my time doing anything to those either. Like a lot of HTML 5, that's garbage I wouldn't put in a website in the first place as it's meaning seems to be -- much like ASIDE -- as presentational as CENTER was.

    All the ABBR stuff in particular is they type of dicking around I'm actually against, since it's not HTML's business to say how to convey that, and users should be used to how their browser of choice handles it, NOT how some artsy fartsy style tries to override that default behavior. If that means every browser handles it different, so be it.

    But that goes back to the reason HTML exists, saying what things are to let the user-agent best determine how to convey that meaning. CSS styling can make it pretty, but overriding the default browser behavior will just be an unexpected behavior for the people who use the "offending" browsers all the time.
    deathshadow, Jun 12, 2016 IP
  3. tomasz86

    tomasz86 Greenhorn

    Likes Received:
    Best Answers:
    Trophy Points:
    Thank you @deathshadow for your comment, despite the critique :)

    I wanted to avoid shorthand properties to make the code more specific and easier to understand for beginners (shorthand for properties like `font` may be confusing). In some cases, such as ABBR using a shorthand `text-decoration: underline dotted` renders the whole style invalid in unsupported browsers. I will consider making the CSS more compact though.

    The !important is used here on purpose to make the point not to mess around with default font-size and outline values stronger but you are probably right that it will be better to remove !important all together from the code, just to avoid any possible inheritance issues.

    Actually I did not know about this one. Are you saying that hex values should be used whenever possible? IE6 supports the rgb syntax just fine so what are the browsers that have problems with it (just wondering)? I personally like to use rgb and convert them to hex later so that it is easier to modify the values on the fly. Yet, if hex syntax is better for legacy support then I will use that instead.

    SUMMARY is included as a solution to the problem, not because I like this particular HTML5 tag. I myself would recommend using HTML4 tags with appropriate style instead but if you do happen to use SUMMARY (either by choice or have it in a code which you cannot change) then at least provide visual cues that the element is interactive.

    I am actually not sure about this one. You definitely have a point here but I am more of a realist. The browsers fail (in terms of accessibility) when it comes to styling elements such as ABBR, anchors and many others.

    In case of ABBR, just some time ago Firefox changed its default style from `border-bottom` to `text-decoration`. As a result, many websites now display both the border and the underline because the `border-bottom` is declared in their CSS. This kind of proves your point that we should not change the browser defaults (yet the developers constantly do it...). However, other browsers (like Chromium) do not style ABBR at all which is a fail in terms of WCAG. In my opinion, going for WCAG compliance is better even if doing so changes the browser defaults. In this particular case there may still be different opinions whether `border-bottom` or `text-decoration` (or even other styling) should be used though.

    The situation is similar for anchors but I think there are two problems here. Firstly, browsers' default colours do not match WCAG. Secondly, most websites use their own colour combination anyway. The colour combination included in accessible.css is both WCAG compliant and also does not really differ much from the browser default which is blue for :link, purple for :visited and red for :active (with the specific values being different in each browser). However, this combination works only for black text on a white background and may not (more likely will not) match WCAG if you use a different text and background colour mix. In such a case you should change the colours accordingly.

    I am certainly against doing a "copy & paste" (and forget). The whole point of the project is to provide improvements to the browser defaults that result in better accessibility. The key word here is "defaults.". As you are saying - every layout is different - and the appropriate styling should be different too! That is why I called the values proposed in accessible.css not universal. They (especially the colour related ones) work well for the browser default styling (which is usually black text on white background) but will need modifications if you want to use them for a different design or layout.

    Accessible.css is basically a collection of tips on how a WCAG compliant website may look like. The code is written in such a way that parts of it can be used modularily (separately). Even if you do include the whole file in your project, you should definitely modify the values, or even remove those which you either do not need or do not want to use. While some recommendations (such as use of sans serif fonts for on-screen view) are out of discussion, this is not the case for others. For instance, there is no requirement to use this particular combination of blue, purple and red for links. Using a different colour combination is not a problem, as long as it follows WCAG.

    My intention is to provide an example, not a norm. I think that most people are either not aware of or simply do not understand accessibility. Even if they know that their website should be easy to use for everyone, they may not know how to accomplish it. That is why I try to include as many references as possible so anyone can check and read the sources themselves. I know that simply following WCAG may not be enough to make all websites accessible but I do believe for it to be a good starting point.

    Anyhow, thank you again and I will keep the thread updated when any changes are made in the future.

    Edit: I have just uploaded v1.0.1. You can check the full changelog on GitHub but among others I have included an additional explanation on the purpose of the project, and replaced "defaults" with "examples" to make it clear that these CSS rules should not be just used as they are, with no modifications, but ought to be rather adjusted for each website / project's individual requirements.
    Last edited: Jun 13, 2016
    tomasz86, Jun 13, 2016 IP