Week 3

:focus you can do more then on click. outline: 0; < bad. Mutiple levels of access. (Level AA etc.)

  • Don't delete styling
  • Otherwise, make it better.
  • Focus and hover same styling.

ARIA; more interactive elements. Roles give more semantic. Don't open links in new tabs. Don't click here links but good descriptions.

  • Sim Daltonism mac app.

Images

  • Decorative; background image
  • Decorative but image; role="presentation" (source set)
  • Iconfonts; svg inline transition stylen etc.

Animation and effecs

Use to make things better, creation of objects.

CMS

  • Give user possibility to do visual design
  • User spends time on style not writing content.

Extending the clickable area; list items. Class disabled versus :disabled.

1. CSS Inheritance

Dividing pages into components. Everything needs to be related. Consistent design with minimal effort. CSS is made for DRY.

Inheritance and font-family

Inheritance is basically local scope for CSS. Available through child scope. You can also make a class and apply it to any HTML element. Give most of the styles in the HTML.

Inherit keyword

[property name]: inherit

Exceptions based styling

Only tweak what you need in the Global scope.

Element styles

We should be styling as many common elements as possible. Element selectors are low in specificity, so they won’t override any class-based styles you might incorporate later.Each time you come to creating a new component, if it introduces new elements, style those new elements with element selectors.

First style the elements you are going to need. You are then not rewriting the same CSS under a different namespace. Element selectors:

  • HTML is less verbose (no reduntant classes)
  • Stylesheet is less verbose (styles are shared between components)
  • Based on semantic HTML

Because classes are designated exclusively for styling purposes and they appear within the markup, you are technically breaking with separation wherever they’re used

Special Cases

To make buttons found in one interface look fundamentally dissimilar is to confound your users. For the sake of accessibility and consistency, most buttons only need to differ in appearance by label.

Attributes

Semantic HTML isn’t just about elements. Attributes define types, properties and states. These too are important for accessibility, so they need to be in the HTML where applicable.

Simple attribute selectors have the same specificity as classes. Using them unqualified means that any classes written further down the cascade will override them as intended.

Just Write HTML

Principally, we need to deal with flow layout — the spacing of successive block elements. That’s because margin should not be considered a property of elements but a property of the context of elements. That is, they should only come into play where elements meet.

  • global (html) styles and enforced inheritance,
  • flow algorithm and exceptions (using the lobotomized owl selector),
  • element and attribute styles

You should be styling the type of element, not the instance of the element. Always remember that the term “class” means “type of thing, of which there may be many.”

Component specific styles

In fact, a good exercise is to identify complex components (“molecules,” “organisms”) by ID only and try not to use those IDs in your CSS.

By using classes prolifically, you also maintain a styling system that is largely separate from your HTML system. This misappropriation of ‘separate concerns’ can lead to redundancy or, worse, can encourage inaccessibility: it’s possible to affect a visual style without affecting the accessible state along with it.

I hope this article has at least gotten you to rethink what components are. They’re not things you create in isolation.

2. Semantic CSS With Intelligent Selectors

In design, you should always lead with function, and allow form to emerge as a resul

Intelligent selectors

Any selector that requires the author to intervene and alter the document simply to elicit a stylistic nuance is an unintelligent selector. The class is a classic unintelligent selector because it is not naturally occurring as part of semantic convention.

However, some unintelligent selectors can become “plain stupid” selectors by creating a mismatch between document structure and presentation. I’ll be talking about the alarming frequency with which the unintelligent .button selector quickly becomes plain stupid.

Viva le differance

This is the whole reason why style sheets were invented: to facilitate physical separation without breaking the conceptual reciprocity that should exist between document and design.

Some of these attributes may improve the semantic detail of your document, while others are needed to ensure the correct rendering and functioning of their subject elements. If they’re not there, they should be, and if they are there, why not make use of them? You can’t write CSS without writing HTML

Auticons; As soon as an editor publishes some content that contains a secure link, the link resembles a secure one to the user. No knowledge of class names or complex HTML editing is required.

File Types

As promised, you can also style hyperlinks according to how their href value ends; determines what the href ends with, using $=:.

Actual buttons are actual

No amount of class name modification via “meaningful hyphenation” can make up for this invitation to turn your unintelligent selector into a plain stupid one and to just code stuff wrong.

Nonetheless, some will insist on using a as the basis of their buttons. Hyperlinks are (slightly) easier to restyle consistently, after all. If a is the element of choice, then there is only one way to make it a close-to-true button in the accessibility layer. You guessed it: You must apply another meaningful attribute in the form of a WAI ARIA role.

Conclusion

There’s no such thing as semantic CSS. There’s only semantic HTML and its visible form. In this article I have tried to demonstrate that, by coupling the function and form of Web pages directly, you can create mechanisms for reward and punishment.

3. How Our CSS Framework Helps Enforce Accessibility

A user interface control not only needs to look like a certain control, it must be described as that control too. It appears our fake button is accessible only to people who can see the screen and use a mouse.

What we have here is the proverbial cart before the horse. The developer has styled the element before describing its purpose. Adding a role does not add behavior. A fully accessible button must be keyboard focusable and it must be invokable. Developers often fall into exactly the same trap as before: they convey the state visually but not aurally. This button will not be described as disabled and it will not behave as disabled.

We must always remember that correctly describing a UI control is only part of making it accessible. The user expectation is that it behaves like that control too. Therefore we must also ensure that the correct accessible behavior is in place.

Summary

HTML provides the aural description and some built-in behavior CSS provides the visual style and interaction clues JS provides any missing behavior not provided by ARIA or HTML

So, the next time you find yourself creating a class name like ‘active’, ‘hidden’, ‘on’, or ‘off’ – stop and think instead how you might be able to leverage HTML properties or ARIA states in your selectors.

results matching ""

    No results matching ""