Friday 31 July 2015

Taking A Break - Vanseo Design

Taking A Break - Vanseo Design


Taking A Break

Posted: 30 Jul 2015 05:30 AM PDT

Do you ever find yourself with far more to do than you have time to do it? That's the situation I'm in at the moment.

I have a few work projects and a few personal projects that I need and want to complete, but despite my best efforts, I haven’t been able to find or make the time to complete them.

Something has to give if I'm ever going to find the time and every which way I look at it, the answer is always the same. The time I need is the time I spend writing here. I need to take a temporary break from that writing, if I'm ever going to complete these projects.

I decided to take the next few weeks off from this blog. Since I've been publishing so regularly and consistently for the last few years, I thought I would let you know that the break is planned.

I'll be back the Tuesday after Labor Day (September 8th) with the start of a series about working with Sass.

Download a free sample from my book Design Fundamentals.

The post Taking A Break appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now

Tuesday 28 July 2015

5 Rules For Using ARIA Roles, States, And Properties - Vanseo Design

5 Rules For Using ARIA Roles, States, And Properties - Vanseo Design


5 Rules For Using ARIA Roles, States, And Properties

Posted: 27 Jul 2015 05:30 AM PDT

How do you know when to use ARIA and when it isn't necessary? What do roles do to native HTML semantics? Are there additional requirements for working with ARIA? All these questions are easily answer if you understand the five rules for using ARIA in HTML.

title
Rules for Maria Knee’s kindergarten class. Image courtesy of Wesley Fryer

The last few weeks, I've been talking about WAI-ARIA. After an introduction and example I walked you through the roles model, including both roles and their supported states and properties.

Today I want to take a step back and focus on another document with advice for using ARIA in HTML. I want to look at the the guidelines provided by the document and consider them something of a summary for this series.

Five Rules For Using ARIA In HTML

As you've seen through this series, a significant part of working with ARIA is in the details. Those details are too numerous to try and present here so I've instead focused on helping you understand how everything is organized so you can find what you need quicker and easier.

Keeping with the same goal, I want to present some general guidelines for using ARIA in HTML. I've mentioned a couple of them in passing, though without much explanation. The W3C refers to them as rules, but I'm not a big fan of absolute rules and I'll bounce back and forth between calling them rules and guidelines.

Here are all five. I've rewritten the first one in this list, since I think the full rule is a bit more confusing. The full rule starts the next section.

  1. If you can use native HTML elements and attributes to communicate the proper semantics and behavior then do so.
  2. Don't change native semantics, unless you really have to.
  3. All interactive ARIA controls must be usable with the keyboard.
  4. Don't use role=“presentation” or aria-hidden=“true” on a visible focusable element.
  5. All interactive elements must have an accessible name.

First Rule of ARIA Use

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

The idea is to opt for writing semantically correct HTML and make use of HTML native semantics before reaching for ARIA.

If the semantics are already included in HTML then the additional ARIA isn't necessary and you should just use the HTML. Adding ARIA support where it's not needed is redundant code that isn't doing anything. For the most part it won't lead to problems, but it is a waste of time.

For example if you're creating a button, then use the HTML button element. However, if for some reason you can't and the button needs to be a div, go ahead and add ARIA semantics to communicate your div should be treated as a button.

You may remember earlier in the year I took a look at some of the new HTML5 structural elements. They map to ARIA roles, but not all browsers support the mapping yet so you would still add roles as in:

1  
<nav role="navigation"></nav>

Again support for mapping some HTML5 elements to ARIA isn't always there and you're better off adding the redundancy and include the ARIA for the moment.

On the other hand most every element from HTML 4 and earlier is already mapped and doesn't require additional ARIA. Writing semantically correct HTML is a huge step in writing documents that comply with ARIA standards.

Still there are some ARIA roles, states, and properties that are not available as features in HTML. You can find a list of them here. If you want to use any of these roles, you'll need to add them to your HTML as they aren't native to any element.

You might also be interested in this table of HTML elements and the ARIA roles, states, and properties which may be used on each element.

Second Rule of ARIA Use

Do not change native semantics, unless you really have to.

When you add an ARIA role to an HTML element, the semantics of the role override the semantics of the element as far as assistive devices are concerned.

Ideally you'll follow the first rule and choose HTML elements that communicate the proper semantics, but sometimes you can't. The Using ARIA document offers an example where you want to develop a heading as a button. One option is to use an h1 and add a button role.

1  
<h1 role="button">heading button</h1>

The ARIA button semantics would override the semantics of the h1, which isn't something you should generally do. Much like the DOM tree, there's an accessibility tree. The code above would become a button in the accessibility tree and not a level 1 heading.

The change only affects assistive devices. The element will still look and behave as an h1 for everyone not using an assistive device.

The change also does't add new states and properties. They would need to be added separately. The change only overrides the native role semantics.

A better option would be to use a button element and wrap it inside an h1.

1  
<h1><button>heading button</button></h1>

The button element already carries the correct semantics for assistive devices so no ARIA role is needed. The h1 still carries its expected semantics as well. A possible third option if you can't use a button element for some reason might be to use a span and give it the button role.

1  
<h1><span role=button>heading button</span></h1>

Once again the h1 semantics aren't overridden and a span is a generic container that can be given the semantics of a button using the ARIA role.

In general choose the best semantic elements and structure and don't override the semantics of the HTML without good reason.

Third Rule of ARIA Use

All interactive ARIA controls must be usable with the keyboard.

This one is straightforward. Any widget you create that can be interacted with through mouse clicks, taps, drag and drop, sliding, scrolling, or whatever should be available through an equivalent keyboard action.

For example buttons should be able to receive focus, likely by tabbing through the elements on the page. Once it has focus hitting the Enter or Return key should be enough to activate the button action.

Fourth Rule of ARIA Use

Do not use role=“presentation” or aria-hidden=“true” on a visible focusable element.

Rule four is the most specific rule as it deals with two specific roles. The idea is that using either on a visible and focusable element will result in some users focusing on nothing.

Adding the presentation role to an element removes the semantics of the element and tells assistive devices the element is for presentation only.

<div role="presentation">Some text</div>

becomes

<>some text<>

in the accessibility tree, which probably isn't what you want.

Elements that don't require children, like an h1, won't remove the semantics of their child elements, but with elements that require children such as ordered and unordered lists, the children would also have their semantics removed.

Similarly, hiding an element for screen readers with the aria-hidden state when it's accessible to non-assistive devices is not something you should generally do, however if the element is also visibly hidden and can't be interacted with it's ok to set aria-hidden to true.

Fifth Rule of ARIA Use

All interactive elements must have an accessible name.

For an interactive element to have an accessible name its Accessibility API accessible name property (or equivalent) needs a value. That's a mouthful, but it's not as confusing as it might sound. For example:

1  2  
name <input type="text">  <label>name</label> <input type="text">

In both lines of code there's a visible label of name for the input, but there's no accessible name. You might ask about the second line with the label, but nothing connects the label to the input.

The code is better written as either of the following:

1  2  
<label>name <input type="text"></label>   <label for="name">name</label> <input type="text" id="name">

Here both visible and accessible labels are included. The first line wraps the input inside the label and the second includes for and id attributes to make clear that the label applies to the input.

Closing Thoughts

Ideally you'll always use the most appropriate HTML elements and structures to convey semantic meaning to assertive devices, but sometimes you can't. Ideally every ARIA role, property, and state would be communicated through HTML alone, but unfortunately some aren't.

ARIA is markup that allows us to communicate important semantics when the native HTML can't. ARIA allows you to define the role of an element or component in the interface, the properties of that component, and their current state.

It doesn't add semantics to HTML. It overrides the native semantics on HTML so be careful that you're adding it appropriately. Follow the five rules for adding ARIA to HTML and you should be ok.

That wraps up this series on accessibility and ARIA. I hoped it helped clear up any confusion you may have had. Later in the year I'll revisit the topic, especially as I promised to fix things on this site to make it more accessible to more people.

Download a free sample from my book Design Fundamentals.

The post 5 Rules For Using ARIA Roles, States, And Properties appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now

Friday 24 July 2015

Why You Should Improve Your Artistic Skills, If You Want To Keep Your Design Job - Vanseo Design

Why You Should Improve Your Artistic Skills, If You Want To Keep Your Design Job - Vanseo Design


Why You Should Improve Your Artistic Skills, If You Want To Keep Your Design Job

Posted: 23 Jul 2015 05:30 AM PDT

Are you sad about the lack of creative looking websites? Do you think too many websites look the same? Do you know how to turn your desire for more creative and unique aesthetics into a selling point for your business?


Note: This post includes an audio version. If you don’t see the audio player above, Click here to listen. You can also subscribe in iTunes

Last week I continued a discussion about the the state of creativity or lack of it in the industry. I offered four reasons for why the web currently looks like it does, and why none of them are bad things.

Today I want to look ahead and, despite it not being necessary for most sites, I want talk about why you should be sharpening your creative pencils so to speak. I'll do it through the same four basic ideas I talked about last week.

I want to talk about more creative aesthetics as a business advantage, what the ever changing technology means, why the art and creativity will come back as they always do, and finally where the next trends and the near future of aesthetics on the web are likely to come from.

One thing to keep in mind throughout, while design is how it works as well as how it looks, this conversation is about how it looks.

Aesthetics as a Business Advantage

I think the choice to have creative aesthetics that wow visitors or not is one of pros and cons and choosing the right balance for you, your site, and your business.

We can complain all we want about one site looking like the next but if the site is successful and its visitors are happy why does it need to be more beautiful?

A beautiful site while nice, is just one thing among many to have a successful business. It is one thing though, and that means you can use your skills creating beautiful websites as a differentiator in your business.

Part of what makes for a successful website is the attention it can attract to itself. Beautiful and creative sites tend to get noticed and talked about so it's one way to gain general attention.

Studies show you have a few milliseconds to convince a visitor to stay a few seconds longer, long enough to direct them through your content. An artistically and creatively designed website can do that. Human beings like to look at things we find beautiful.

A creative site can hold attention beyond a few milliseconds, where you can then direct people to important content, which is ultimately what keeps them there and brings them back.

If your site looks like everyone else's site there's not much to distinguish you from the next search result. If on the other hand the first time someone lands on your site, your aesthetics wow that person, it's more likely they'll stick around, remember you, and come back again.

That doesn't guarantee a sale, but it makes getting over the initial hurdle of keeping someone on your site more than a few milliseconds more likely.

Your site still needs to be well designed so visitors can navigate it and find what they're looking for and it needs to be easy to contact you and pay you, etc. A creative and beautiful site can help you get to those things, which is much harder to do than we like to think.

There are plenty of studies to show that people will spend more time with a site they consider aesthetically pleasing, keeping them more engaged and more likely to learn the interface. They think the interface is easier to use when they like how it looks. A more beautiful site can lead to improved usability.

Early in the year I talked about the smiling curve and how we need to move to either end of the curve to retain clients. At one end was scale and productivity and at the other was scarcity and creativity.

Designing more unique and creative websites is one way you can stay in business as the market changes. All the things being blamed for lacking soul help you stay in business at the other end of the curve.

Time to Specialize

Industries mature over time. Web design is still a new industry. For much of the last 20 years, web design has been the wild west where anything goes. The industry is starting to grow up, though.

People have been and will continue to specialize in different aspects of web design. I think everyone who works on a website should understand the general basics of things like performance, usability testing and any other web design topic.

We should all know the basics of everything that touches the creation of a site. Every day though, it's harder and harder for a lone individual or even a small team to do everything well in the creation of a website.

I'd bet that the majority of websites that are built today are built by a lone designer or developer who finds tools to help with the parts of the site he or she has difficulty with. If we're all using the same handful of tools our sites are going to look similar.

We're at a point where you're going to see more and more specialization. If you're someone who's interested in how websites look, you should probably start specializing in designing sites that look better.

If it will be a business advantage then people are going to look for designers who can deliver beautiful and creative aesthetics. Why not make it your specialty? I think there will be more SquareSpace and DIY sites that look the same and if your site is different it will stand out. People will look for that advantage.

The best part is the people who will appreciate your aesthetics for their aesthetic quality are usually the same people who are willing to spend more money for the greater value they place on those aesthetics.

It's a good niche to serve in any market. See Apple. Not everyone prefers Apple's products, but those who do are generally willing to spend more to get them, even if they are minimalist designs that seem to equal a lack of creativity in the eyes of some in our industry.

Art and Creativity are Part of Being Human

I mentioned last week that it's human nature to copy the success of others. It's also human nature to desire creative, beautiful and artistic things. We've been creating art for at least 40,000 years, which I think is the age of first cave painting. We've probably been creating art longer than that.

Human beings communicate visually, through symbol and icon. We read each other's facial expressions and body language. Certainly not all, but most people probably trust what they see over any other sense.

We also like beautiful things. Regardless of the medium, it's in our nature to want whatever goes into that medium to be beautiful. To deny that human beings like art is to deny being human.

We can talk all we want about beautiful aesthetics not being necessary and costing too much. We can talk about the web being more in favor of better development and functionality, but as a species we seem to keep coming back to this art thing no matter how often the medium changes.

A more creative aesthetic will become an ingredient of web design again, because it's an ingredient in human beings designing in every medium that's ever been.

People have added art to designed objects for a long time. Go to a museum and look at all the vases, tableware, pottery, etc. These are designed objects and not art.

They weren't created to be art. They're products that have been given an artistic treatment. They weren't created to sit in the corner and be looked at and admired. They were created to be used, but since they were being created why not make them as beautiful as possible.

And now several thousand years, they're still around.

Art and creativity exist for reasons beyond the success or failure of a website. Art is among the most important things for any society as it often leads where society goes. More art and more creativity everywhere are good things in my opinion.

Where Will the New Aesthetic Come From?

Like I said last week the current trend will change. Something will replace flat design. I don't think we've found the general aesthetic for the web yet. We've borrowed aesthetics from print, but the web isn't print.

It made sense to borrow from the past when starting, but we've reached a point where we're ready to do what comes next. I think the future web aesthetic will play to the strengths and weaknesses of the web. It will play to the fundamental truths of the medium.

The strength of the web is the dynamic and flexible nature of the medium. That's also its weakness. You don't know how your site will perform for any particular visitor or what size the window that the visitor will peer through to see it.

Like it or not we need to create on top of systems that are flexible and dynamic, because the web is both. We don't get to control that. We have to ensure things work before anything else.

I keep looking to apps and mobile devices for where we're heading. I wish websites in browsers could do more of what apps in mobile operating systems can do. I'd like to see more and better use of gestures. I'd like to see haptic technology work its way into websites. Perhaps we'll feel the depth in the future instead of seeing it. But those aren't really about visual aesthetics.

The flexible and dynamic nature of the web suggest we should be looking to SVG and light animation. I've been thinking that creative uses of SVG will be what breaks us out of our so called "boring design doldrums."

One reason for the lack of creativity is that it can downgrade performance. It typically means more images and more http requests. We've elevated performance to a higher priority, which means less images and less http requests.

SVG is code so it improves performance by replacing the need for some http requests. It works well, especially in this performance hungry time. It's a good next step. I can see designers working with basic shapes and lines and other fundamental elements of graphic design, through the use of scalable vector graphics. I'm sure we'll start by copying from print, but we'll do things differently in time.

Combine SVG with CSS like masking and blending and before long we're going to be able to do with code what we've relied on graphic editors to do.

Part of the sameness we have is a result of having to design inside rectangles. That will change. Things like css shapes and exclusions will break us out of having to design with rectangles. We'll be able to design inside any shape we want.

A lot of creative possibilities are going to open up as the technology improves and these possibilities will work with the fundamental nature of the web as opposed to working against it.

I also expect more movement in the web's aesthetic. Movement is a huge advantage the web has over print. A moving picture can communicate more than a static one.

I don't mean to suggest that every site will have animated characters moving across the screen. No one needs another Microsoft Clippy. However, instead of menu items changing color instantly on hover, the changes will take place over a few milliseconds. We're already seeing this happen. Elements slide in and fade out, and we make all sorts of changes over a time as opposed to instantly.

I also expect to design more with proportion than absolute size. Stop using px and use more relative measurements. It's less important that A = 1 and B = 2 and more important that B is twice A. What's important is that A can change from 1 to 2 to 3 and back to 1 again while B remains twice A.

We should be measuring in relative sizes like percents, viewport width and height, and ems. I think for many it will be challenging to make this change. It took me a few sites to wrap my head around it, but I think it will also open up more creative possibilities in how one part of a web page relates to another and where each part is located as the page reconfigures.

Hopefully the future sees more progressive enhancement. We have no idea what devices and conditions will exist when someone visits a site we design. We'll have to determine the minimum for which we'll build and then build a system of layers from that minimum to the latest and greatest.

We'll create layers of progressive aesthetics. Flat design or something like it will likely remain one of the layers closer to the minimum. Flat design for sites that can't handle animation and SVG.

We tend to think of mobile as least common denominator while we work on our laptops and widescreen desktops, but is it? In many ways we can already do more on mobile devices than on some older browsers still in use.

Regardless of what the next trend is, I'm sure it won't come about because we're talking about it and deciding what it should be while we criticize what we have and what has come before.

The next trend will evolve like most do. One designer will create something new, others will see and build on it, and as a group they'll create something others will copy en masse.

Then it will become a trend. Some will like the new trend and some will dislike it. Then the pattern will continue and another trend will emerge and then another. Each trend will leave behind something permanent that becomes part of a general web aesthetic.

I also know each trend and each permanence left behind will be criticized for not being something else. Each will be hailed as the greatest thing since fire, sliced bread, and the wheel at the exact same time it's being panned for not being the same as it's always been.

Closing Thoughts

I personally want to see more creative sites that look beautiful and force my mouth to open with an emphatic wow. At the same time I know that's not necessary to do business on the web and like it or not our job is usually to help someone sell more of something.

However, just because it isn't necessary, it doesn't mean there aren't advantages to creating beautiful and awe inspiring sites. You want your business to stand out from the competition and creative aesthetics are one way to do that.

Given the business advantage, I expect the ability will become a specialization for those who are the creative leaders in our industry.

Art and creativity are good things that human beings desire. They will come back because some of us will want to put them back for their own sake. If you got into web design in part because you enjoy being creative, it stands to reason you'll want to add more creativity to you work at some point. A desire for artistic, creative, and beautiful things is part of being human after all.

One last thought is for everyone to have some perspective. Web design trends probably won't change as often as trends in the fashion industry, which has a new look every year, but compare it to a movement in art like impressionism which was probably the dominant trend in the painting for about 20 or 30 years.

We're talking about things that have been with us two or three years and acting like it's been 100. Give the industry a break. Give it some time to figure a few things out.

In the end I know discussions like this one aren't going to be what leads to the aesthetic we find. That will come from working designers. For those people who are complaining about how the web looks and are talking about what it should look like, stop talking and start designing.

If you put more creative and more soul into your own designs and you're successful with them, people will copy you while will lead to more creative and more soul to more sites. That's how you'll end up with more creative websites. Just design more creative websites.

Still if a conversation like this one helps convince one designer to be more creative, it will be worth it. That's why I'm having the conversation and why I hope others are as well.

I do think art for the sake of art, creativity for the sake of creativity, and beauty for the sake of beauty, have always been and always will be worthwhile pursuits.

Download a free sample from my book Design Fundamentals.

The post Why You Should Improve Your Artistic Skills, If You Want To Keep Your Design Job appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now

Tuesday 21 July 2015

The ARIA Roles Model Part 2 - Vanseo Design

The ARIA Roles Model Part 2 - Vanseo Design


The ARIA Roles Model Part 2

Posted: 20 Jul 2015 05:30 AM PDT

There are a lot ARIA roles, states, and properties to remember. Add in all the details of each and it's unlikely you're going to memorize all of ARIA. I suspect most of us will need to look things up more often than not. Fortunately the roles model can help us do just that.

title
A UML diagram of the ARIA roles model

Last week I started talking about ARIA'a roles model. I talked in general about the taxonomy behind the model, how roles are organized in a hierarchy, and how different roles are related to each other. I closed last week's post talking about the different characteristics of roles.

Today I want to continue talking about the roles mode, specifically how roles are organization into four categories. Then I'll talk about the supported states and properties of roles and how these attributes are grouped and organized.

Categorization of Roles

I mentioned a few times last week that the ARIA roles model is a taxonomy and in part that means grouping them all under different categories. ARIA roles are divided into four major categories.

  • Abstract Roles
  • Widget Roles
  • Document Structure Roles
  • Landmark Roles

Abstract Roles are used to define general role concepts. There are 12 in total and they serve as the building blocks for all of the other roles. If you look at the roles model diagram at the top of this post, you'll see there's a widget role, a structure role, and a landmark role (the other three categories) and all three are abstract. Each serves as the base type for a group of roles.

Abstract roles are used by browsers and offer no additional semantics to assistive devices. You won't ever use them. In fact the spec explicitly states authors must not use abstract roles in content and the words "must" and "not" are bold and entirely in capital letters so you know it's really important.

Widget Roles are used for interface widgets and there are 34 widget roles in total. They can describe complete widgets in and of themselves or be component parts of a composite widget. For example cells in a grid would get the role gridcell, while the complete grid would get a role of grid.

Widget roles are even divided into those that act as standalone items in an interface and those that act as composites, usually containers for the standalone widgets. To give you an idea what's considered a widget, here are the nine roles for composite widgets.

  • combobox
  • grid
  • listbox
  • menu
  • menubar
  • radiogroup
  • tablist
  • tree
  • treegrid

The other 25 widget roles are standalone widgets like a progressbar or something like a gridcell meant to be used as a component inside a composite widget.

Document Structure Roles are about content. There are a total of 19 of them and they describe the structures that organize content on a web page. They are generally not interactive, but some could be.

Two of the roles I mentioned when talking about HTML5 sectioning elements, article and region, are included in this group. In an ideal world you would use the article element (article role) or the section element (region role), however not all browsers currently support the mapping, so for now you probably want to use both the element and role. In time we'll be able to skip the redundancy.

Landmark Roles exist to help assistive devices navigate web pages. There are 8 landmark roles in total and they help define the big picture structure of your page. Five of the eight will be familiar to you if you read my aforementioned series on HTML5 structural elements.

Since there are only eight I'll list them all here.

  • application
  • banner
  • complementary
  • contentinfo
  • form
  • main
  • navigation
  • search

All content on a webpage should be inside a container with a landmark role that makes the general region accessible. The role might be communicated through native HTML, but either way the semantics should be there. It helps make every piece of content on your web pages navigable.

Stop for a moment about these categories. One of them, abstract, you won't ever use. Of the other three, landmark roles describe the more general and higher level parts of your layout, your main page header and footer, your main content area, and any sidebars you might have.

These general parts will be filled with content (document structure roles) and interactive widgets (widget roles). A few of the landmark roles like navigation, and search might be thought of more as components within the layout, but as they're usually included on every site, they can be considered as higher levels parts of the layout.

Supported States and Properties

As we saw last week, one of the characteristics of all roles is that they support certain attributes. All roles have supported states and properties, some of which are required, and some of which are inherited from a superclass role.

States and properties refer to similar features. Both describe the objects they're applied to and contribute to the definition and nature of the role. While they're similar, there are some differences to distinguish one from the other.

The values of properties are less likely to change than the values of states, which will change with user interaction. For example if you associate a checkbox with a label you wouldn't expect the label to change so properties like aria-label and aria-labelledby would remain constant.

On the other hand checkbox is sometimes checked and sometimes unchecked so a state like aria-checked is expected to change. Some properties like aria-valuenow are also expected to change often lessening the distinction.

Another difference is that properties are essential to the nature of a given object. Changing a property could significantly alter the meaning or presentation of an object. States on the other hand don't affect the essential nature of an object, but represent data associated with it.

You'll find both referred to as ARIA attributes. Like roles they're added as attributes to HTML elements and they all take the form aria-*

1  2  
<span id="check" role="checkbox" aria-required="true" aria-checked="false" />  <label for="check">Check Me (required)</label>

Here checkbox is the role, aria-required is a property of the role, and aria-checked is a state of the role. When states (and some properties) change their values through user interaction, such as checking and unchecking a checkbox, screen readers are notified of the change.

There are a total of 10 states and 35 properties and like roles I don't expect either of us to memorize them all. Here are the states.

  • aria-busy
  • aria-checked
  • aria-current
  • aria-disabled
  • aria-expanded
  • aria-grabbed
  • aria-hidden
  • aria-invalid
  • aria-pressed
  • aria-selected

Hopefully the names alone are enough to know that the values of any of them can and likely will change.

Value Types of States and Properties

The values of all states and properties will be one of the following types. I assume most are self-explanatory, but where you might not (ok where I didn't know) the specific definition, I added it.

  • true or false
  • tristate (true or false with an intermediate "mixed" value)
  • true, false, or undefined
  • ID reference (of an element in the same document)
  • ID reference list (a list ID references)
  • integer
  • number
  • string
  • token (limited set of allowed values)
  • token list (list of tokens)
  • URI

An undefined value is often allowed as an explicit declaration that a state or property isn't set.

Taxonomy of States and Properties

Like roles, states and properties are grouped into four base attribute types, each with a number of specific states and properties.

Widget Attributes are specific to common graphic user interface elements and rich internet applications that receive user input and process user actions. Most states are widget attributes. In fact, 7 of the 10 total states are widgets states.

An example of a widget attribute is aria-required for any input that's required and an example of a widget state is aria-checked to indicate whether a checkbox is checked, unchecked, or mixed.

Live Region Attributes are for live regions in rich internet applications and they can be applied to any element. There are four live region attributes, one of which, aria-busy is a state.

Live region attributes exist to indicate that content changes may occur on an element, even when the element doesn't have focus. They also provide information to assistive devices for how to process the content updates.

An updating stock ticker is an example of a live region. Updating sports scores or weather information are also good examples.

Drag-and-Drop Attributes provide information about drag-and-drop interface elements. There are only two attributes, aria-dropeffect, which is a property and aria-grabbed, which is a state.

The aria-dropeffect property indicates what can happen when a dragged object is dropped on the target area. The aria-grabbed state indicates if an element has been grabbed or is capable of being grabbed.

Relationship Attributes specify relationships or associations between elements which cannot be easily determined from the document structure alone.

For example to know how many columns a gridcell spans you would need to first know the entire structure of the grid. The aria-colspan property can communicate the information as soon as the gridcell is encountered.

All 14 relationship attributes of ARIA 1.1 are properties.

Global States and Properties

Of the 45 total attributes, 18 of them are global, because they're applicable to all elements regardless of whether a role is applied. These 12 properties and 6 states are supported by all roles and by all base markup elements.

Global states and properties are applied to the roletype role, which is an abstract role that all other roles inherit from.

If you were adding up the numbers I mentioned for each group of attributes you may have notice they add up to 43 and not 45. That's because two of the attributes are global only and not included in any of the attribute groups.

  • aria-current (state)
  • aria-describedat (property)

Closing Thoughts

Roles are organized into four major groups, abstract, widget, document structure (or just structure) and landmark. I think the groupings make it a little easier to understand the purpose of each role.

Abstract roles are not to be used by content authors. Landmark roles are for the big picture areas of your layout and widget and structure roles are for what's inside the landmark elements.

All roles have supported states and properties or attributes when they're talked about together. They differ in that states are usually for interactive parts of the page that may change. Some states and properties will be required for a given role and some will be inherited from a superclass.

Like roles, states and properties are organized into four major types, with some attributes also considered to be global. Like roles you don't need to memorize the details of each. Instead make sure to bookmark the pages listing them all so you can quickly find the details you need.

I have one last post in this series before moving on to another topic. Next week I want present some general guidelines for working with ARIA as part of how to use ARIA when writing HTML.

Download a free sample from my book Design Fundamentals.

The post The ARIA Roles Model Part 2 appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now

Friday 17 July 2015

Web Design Has As Much Soul Now As It Did Before - Vanseo Design

Web Design Has As Much Soul Now As It Did Before - Vanseo Design


Web Design Has As Much Soul Now As It Did Before

Posted: 16 Jul 2015 05:30 AM PDT

Have you been following all the talk about the lack of creativity and the lack interesting aesthetics that the web design and development industry has producing the last few years?


Note: This post includes an audio version. If you don’t see the audio player above, Click here to listen. You can also subscribe in iTunes

A couple of months ago I recorded two podcasts about art direction and how important it and aesthetics in general are to the success of a website. By the time I published them, which was a little more than a month ago, I had come across quite a few articles, podcasts, and presentations elsewhere talking about the general subject. For a change I think I might have timed a topic well.

The general conversation is about the sameness in looks from one site to the next and often this lack of originality is pinned on a lack of creativity in the industry. You hear things like:

  • Web designers lack creativity or aren't utilizing the creativity they have
  • Web design has lost it's soul
  • Flat design is killing web design because it allows too many non-designers to design mediocre sites
  • It's the fault of responsive design, frameworks, modern workflows, having to use the wrong graphic editing tools or not being able to use the ones you want

If those complaining are doing so from a desire to inject more creativity into the design of websites, I'm all for that. We should all express more creativity in our work. However, I think the things being criticized as the cause of this lack of creativity are generally good things.

The web looks a hell of a lot better than it did 15 years ago when I first got online. I think it looks a lot better than it did 5 years ago. Better is certainly a subjective word, but in my opinion the web looks better today than it did in the past.

I want to offer some reasons for the current state of design on the web and why nothing is really wrong. Despite my thinking that things are in better shape than some would suggest, next week I'll offer some thoughts on why you should be improving your artistic and aesthetic skills and where the next trends will likely come from .

I realize I may repeat myself talking about this again so soon, but I think this is an important topic and one that potentially determines whether you and I will be working designers in a few years

While design is both how a thing works and how it looks, in this post I'm mainly concerned with how websites look and not so much how they function, which is a separate conversation for another time.

My Context

Let me start with how I feel personally about this. I like art and art direction. I like to see beautiful, creative aesthetics when I visit a website. I think making websites beautiful is worthwhile for no other reason than to make them beautiful.

In some ways this is a difficult topic for me. What I want is more creative, beautiful aesthetics, but I know the reasons the web might not appear creative today are generally good things and they aren't likely to change back.

I want to offer four reasons for the state of design on the web

  1. It's good for business
  2. The medium and technology are changing quickly
  3. The current trend of flat design does play a role though not the one people think
  4. It's human nature

Business Before Aesthetics

As much as I might want every website to be as beautiful as it can be I know most websites don't need to be beautiful or creative to succeed.

The look of a site contributes to the success of that site, but it's not the only thing that does nor is it the most important thing that does. The look is one layer on top of other layers that contain things like content, performance, information architecture, etc. The look is one of those things, but it's just one of them.

There are plenty of examples of very successful websites that look awful and many more examples of generic looking sites that are successful.

Business comes first. Despite wanting to be creative when designing websites, you and I first have to stay in business which means solving the problems of real clients. More and more of my clients just want something that works, doesn't look bad, and doesn't cost much.

Serving those clients means using more frameworks, component libraries, and a simpler design aesthetic that looks good enough and works well. It also means not doing some things that you know might be better for a site, but exceed the client's budget and so can't be included.

As a business owner my goal is to create and build the best site I can for my clients within constraints they set. Their budget is usually the constraint that constrains the most. If you want to stay in business then you need to continue to find more cost effective ways to deliver your services to your clients. If that means using a framework or customizing a theme, so be it.

At the start of this year I talked about how I see the market for freelance design and development work changing. DIY tools and services like SquareSpace can't do what we do, but they've become good enough for many people wanting websites.

If our clients are no longer willing to pay what they have been for our services, we can either find new clients, figure out how to offer our services for less money, or change businesses or careers. Most of us will probably look to reducing our costs to serve the same clients.

Again that means more frameworks, customizing ready made themes, and using component libraries that are shared from project to project. Yes, there's a sameness across many sites, but it's because that's what the market is willing to pay for.

Let me clarify that I mean certain segments of the market, but the ones with the majority of our clients.

Web designers might not like it, but tough. Suck it up. The internet and technology in general has been disrupting every industry for the last 20 years. Guess what? Now it's disrupting our industry through low cost, good enough solutions.

It seems weird since our industry only exists because of the web. For last 20 years people have been building web design careers and still will in the future. The industry is getting disrupted by it's own technology, though.

While I may think a creative, beautiful, custom site is the better option, it's not a requirement for the success of most websites. Most people will make their choice about design based on a subjective opinion of what looks good enough to them and an objective opinion about what costs less.

The Changing Technology and a New Medium

I'd bet most people currently working as web designers had little to no graphic design background when they started. I know I didn't. That might seem like an argument in favor of those who say the creativity is missing, but it isn't.

Web design does not equal graphic design. They're similar in many ways. They both create 2-dimensional designs that appears on a flat surface and the look of the design is what most of us notice first.

But screens are not paper. Each has its own challenges, strengths and weaknesses. Our industry has tried to force the web to act like connected sheets of paper for years. It didn't work. It doesn't work. It won't work in the future.

Trying to make the new resemble the past is typical of how new industries start, but in time they change and play to the strengths and weaknesses of the new. As a new industry matures it leaves it's origins and aligns itself with the the pros and cons of the new things it deals with.

In a few years we went from designing everything inside of 1024×768 or 1200×800 to having to design for a seemingly infinite variety of sizes and resolutions and capabilities. It's a lot more than we would have had to deal with pre-internet.

Lets give the industry a break. There have been and will continue to be a lot of technical things to figure out about the medium in which we work. The web of the future is not going to look like a print magazine from 50 or 75 years ago.

Our print ancestors didn't figure things out overnight and they had arguably less things to think about when designing, given the medium. Why do we forget that?

Responsive design is five years old and most of the industry didn't even notice it in the first year before they started panning it in it's second year. It takes time to figure these things out and while people are working on technical issues because they have to, they aren't focusing on the creative side of things as much.

The Flat Design Trend

Speaking of the last few years there's the flat design trend. I know it's a trend because it's there in the name. The thing with trends is they get replaced with new trends in time. That might be next month and it might be 10 years from now, but there will be a new trend to replace flat design. It's how trends work.

Flat design as a trend is two or three years old. Why do we sometimes act like it's the only way a website has ever looked?

Flat design is a reaction to the previous trend of skeuomorphism. I think of flat design as a return to the fundamentals of type, color, and layout, and images.

The previous trend, skeuomorphism was good at first, but it grew way over the top and the trend that replaced it stripped everything away but the basics.

That gives us a chance to build on top of the fundamentals in a way that's in harmony with how the web works and not force it to look like print. The back to basics is also good education for a large part of the industry, myself included, that didn't go to school to learn graphic design.

Flat design favors minimal and simple. We live in a complicated world that seems to grow more complicated and complex all the time. Is it any wonder we crave simplicity and minimalism in our aesthetics?

Would you rather return to how the web looked in the late nineties and early oughts when it wasn't so minimal. Look up some sites on archive.org if you weren't around or don't remember 15–20 years ago.

It isn't just web design. Minimal photography is a thing as is minimalism in product design. Look around, most creative endeavors have a minimalist aesthetic practiced by some.

One more complaint I hear about flat design is that it features low information density. I don't know about your clients, but my clients don't hand me a lot of dense information. I once had to design a site around less content than you'll find in this sentence. I usually have to solve the problem of designing around too little content than too much content.

Monkey See, Monkey Do

I think the biggest reason for the sameness across sites is that designers copy one another. People now like to point to the last trend of skeuomorphism as something with more creativity and soul, but seriously did you think the last site you visited with a textured paper background and grunge brush strokes was creative or a copy of the thousand paper background sites with grunge brush strokes you'd seen before?

Maybe it's just me, but all those "creative" sites looked very much the same. I wasn't seeing any soul, magic, or creativity in those designs. Just a lot of people copying the existing trend the same way they are now.

Maybe it's not so much the trend as it is an industry that can't stop copying each other. Actually I'm pretty sure it's not our industry. It's human nature. Human beings copy what's been shown to be successful. We've been doing it forever and we'll probably continue to do it forever.

Creativity is hard work. It requires effort that most people aren't willing to put in to achieve the results they want. Copying and tweaking is a lot easier.

I guarantee that if a few sites add more of the creative back in and receive favorable reviews for their work, everyone else will copy what they did.

The current state of web design has just as much soul as any other current state of anything involving human beings. A few people create and share their soulful, creative work. Everyone else copies them.

Things look more the same now, because of the back to fundamentals trend. We're only working with the fundamentals so there's less to work with and so less to differentiate one site from another. But it's really no different than what's gone on throughout human history. Some create, more copy.

Why is Any of This a Bad Thing?

One complaint about the current state of web design is that non-designers can just slap a coat of flat design trend on it and keep working. Yeah, so what?

That's not a bad thing. It might be bad for the designer who previously designed that site, but it's good for everyone else. It's good because it makes design more accessible to more people.

It's no different than you or me using WordPress or whatever content management system you prefer. I chose WordPress because I'm not a developer. I chose a tool that would let me do my thing while letting the tool take care of the things I couldn't do well.

A better solution for me would be to build a custom content management system tailored to my specific needs or hire someone to build it. I also know if I had to develop it myself or pay someone else to, I never would have been in business.

Matt Mullenweg often talks about the goal of WordPress. He wants it to democratize publishing and I think that's a very worthy goal to aspire to.

All the good enough DIY design tools and services, the frameworks, component libraries, and even a trend that can be slapped on, help democratize design.

They may not be good for the bank accounts of web designers, but they are good for most people and quite honestly they improve the overall look of the web. The typical website today looks far nicer and is generally easier to use than the typical website from few years ago and certainly a decade ago.

Closing Thoughts

My apologies if I repeated myself too much. I tried not to, but it was inevitable that I would to some degree.

I've been designing and developing websites for about a dozen years. There has never been a moment during the last 12 years where something in this industry wasn't being criticized.

In some ways that's good. If we have discussions like these, they hopefully get people thinking about how to make things better.

In a lot of ways though, it's just complaining. I'm sure that sometime in the not too distant future the look of the web will change again. Sites won't look like they do now and more designers will be experimenting and putting the creativity back.

Then people will talk about how the industry isn't adhering to conventions and standards and how websites everywhere have become unusable messes. It's the natural cycle of things.

Next week I want to argue more for the other side about why you should improve your artistic and aesthetic skills so you can create more beautiful sites.

I want to offer reasons why you should push the creative envelope. I also want talk about how despite the seeming lack of creativity on the web, the art and creativity isn't going away for long no matter what we do or say.

I'll finish with some thoughts about where I think the future of web aesthetics and the next trends will likely come from.

Download a free sample from my book Design Fundamentals.

The post Web Design Has As Much Soul Now As It Did Before appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now

Tuesday 14 July 2015

The ARIA Roles Model Part 1 - Vanseo Design

The ARIA Roles Model Part 1 - Vanseo Design


The ARIA Roles Model Part 1

Posted: 13 Jul 2015 05:30 AM PDT

What can you do when the native semantics of the HTML you use don't communicate enough information or they don't communicate appropriate information to assistive devices? You use ARIA roles, states, and properties to communicate the semantics instead.

title
A UML diagram of the ARIA roles model

Last week I began a look at WAI-ARIA. I talked about why ARIA exists and offered a quick introduction to the three ways you can communicate semantics using it. Then I walked through a simple example using roles, states, and properties to add semantics to a non-standard checkbox.

I want to talk in more detail about all three over the next two weeks. I want to look at the taxonomy behind the roles model and their supported states and properties. I'll start today with roles. Next week I'll finish talking about the roles model and then talk about supported states and properties.

Similar to the principles and guidelines of the Web Content Accessibility Guidelines (WCAG), the number of roles, states, and properties are too many to walk you through each individually. Instead I'll again point you to resources where you can find the details. Consider this more of an overview of ARIA to make it easier to find and understand those details.

Assuming my skills counting and performing simple math are good, there are a total of 73 different ARIA roles, which is a lot to try to memorize, especially when you add in the states and properties of each.

Fortunately ARIA roles, states, and properties are organized in a taxonomy called the roles model. Understanding this taxonomy can help us understand the purpose of each role and which states and properties are available to it.

ARIA Roles

Adding an ARIA role to an HTML element overrides the native semantics of the element. Adding an ARIA role won't change how an element looks or works, but it does change the semantics communicated to assistive devices.

Pretend you want to create a button. For some reason you can't use a button element and you decide to use a span instead. Unfortunately spans aren't buttons, so you write CSS and Javascript to make the span look and function like a button.

You code is still a non-semantic span to assistive devices, though. To communicate that the span should be treated like a button you can add a role of button that includes the proper semantics for screen readers.

1  
<span role="button">Click Me</span>

Adding the role provides assistive devices information about how to interpret and treat the element. Assistive devices receive a description of the role along with the states and properties the role supports.

Also communicated are hierarchical relationships with related roles such as the treegrid role being a subclass of the grid role. Assisted devices also receive information about a role's context so they understand a gridcell should be inside a row. The hierarchy allows for semantic inheritance between roles as well.

And since specifications beyond WAI-ARIA exist, references to related concepts in other specs are also communicated though the role.

One thing to note is that roles are element types and their values should not change over time. If something should carry the semantics of the button role, then it should always carry those semantics. If you want to change the role, you should remove the element and it's descendants and replace them with a new element and new descendants with the appropriate semantics.

Relationships Between Concepts

ARIA roles are based on concepts outside of ARIA and they're organized into a taxonomy of classes, superclasses, and subclasses. The UML (Unified modeling language) diagram at the top of this post shows the taxonomy. Click on the image for a larger view. You might want to keep it open in another tab while you read.

Don't worry if the organization makes no sense at first glance. It should by the time you finish reading next week's post.

If you look in the top left of the roles model diagram, you'll find the range role (just to the right of composite). It includes four aria-* attributes, which I think you'll agree make sense for something called range.

  • aria-valuenow
  • aria-valuemin
  • aria-valuemax
  • aria-valuetext

One of the subclasses of range is the slider role (directly below range in the diagram). Subclasses inherit all the attributes of their superclass, so the four attributes for range are also attributes of slider. Slider then adds one additional attribute, aria-orientation.

Roles have base concepts that serve as prototypes. For example the the base concept for the button role is an HTML button. There is no inheritance from base concept to role. If the definition of an HTML button were to change, it wouldn't affect the ARIA button role.

Roles also have related concepts. They share similarities, but they aren't identical. For example buttons and links are similar. You can click each and something will happen. They're not the same thing, but they are similar. Related concepts do not inherit properties from each other so changing one doesn't affect the other. A new definition for a button would have no effect on the definition for a link.

Characteristics of Roles

The characteristics of a role define and describe the role's place in the interface, its structural function, the concepts behind it, and the supported and required attributes it contains. The roles taxonomy defines eight characteristics that are communicated for each role.

  • Abstract Roles
  • Required States and Properties
  • Supported States and Properties
  • Inherited States and Properties
  • Required Owned Elements
  • Required Context Role
  • Accessible Name Calculation
  • Presentational Children
  • Implicit Value for Role

Abstract Roles are the building blocks for the other roles. Content authors shouldn't use them. User Agents shouldn't do anything with them. The spec goes as far to say that you must not use them.

They exist to help:

  • Organize the role taxonomy and provide roles with a meaning in the context of known concepts.
  • Streamline the addition of roles that include necessary features.

I'll talk a little more about abstract roles next week when we look at how all the roles are categorized.

Required States and Properties are those states and properties that must be set for a given role. For example a checkbox without checked and unchecked states isn't much of a checkbox so the aria-checked state is required for the checkbox role and it must be set.

Supported States and Properties are those available to the role. Content authors can add them, but they don't have to. Supported states and properties have default values and authors may rely on them instead of explicitly setting a value.

Since all these states and properties should be available to content authors, user agents are instructed that they must map them to an accessibility API.

Inherited States and Properties are those that are inherited from a superclass role in the roles taxonomy and not from an ancestor element in the DOM.

They're inherited and not explicitly defined on the role. The inheritance is automatic. Combined with supported states and properties they form the complete list of states and properties. In other words all attributes of a role are either inherited or explicitly supported.

Required Owned Elements are a little more complicated to explain. Some elements only exist inside other elements. For example a listitem will always be contained inside a list. The listitem is thus a required owned element of a list.

Some roles will have several required owned elements. For example a menu should have at least one instance of a menuitem, menuitemcheckbox, or menuitemradio. All three are required owned elements in that they need to be contained in a menu. The menu isn't required to use all of them. It need use only one, but it must use at least one.

Required Context Roles are like required owned states in reverse. For example listitems only make sense inside a list so a list is a required context role for a list item role.

When a role has a required context you must ensure it's contained inside (owned by) the required context role. The required context role is the owning role and the required owned element is the role being owned.

Accessible Name Calculation are names user agents use to convey information to assistive devices. These names can come from the author of the content or the content itself.

Authors can explicitly name elements through properties like aria-label and aria-labbelledby to make clear the name of the element being labelled.

The text of the element may also be used by the user agent in addition to the name set by authors and in some cases can be used in lieu of the name set by content authors. If you're interested the link a couple paragraphs back will give you details about the calculation.

Presentational Children are children of an element that are there for presentation only. They have no semantics to communicate and user agents shouldn't expose them though an accessibility API.

Implicit Values for Roles are non-standard default values. Many states and properties have default values, but sometimes these defaults should be different based on the role that uses them.

The role indicates this through an implicit value, which creates a new default. If an author explicitly sets a value it overrides either the natural default or the implied value for the role.

Closing Thoughts

The roles model is a taxonomy for organizing all the ARIA roles, states and properties. Roles are organized hierarchically through classes, superclasses, and subclasses. The hierarchy establishes relationships between different roles and provides a mechanism for semantic inheritance.

Roles can have a variety of characteristics including required, supported, and inherited states and properties, which brings us to next week's post.

Next week I'll look more at the supported states and properties after finishing this discussion about roles. I'll talk about the four types of roles that are used to categorize all roles.

Download a free sample from my book Design Fundamentals.

The post The ARIA Roles Model Part 1 appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now