Welcome to episode nine. Today’s podcast is from Myles Eftos, one of the authors of the Sitepoint book, Build Mobile Websites and Apps for Smart Devices , and the Learnable course, Build Mobile: Develop websites and apps for smart devices . In this episode, Myles talks about designing for mobile platforms.

View original post here:
DesignFestival: Design Festival Podcast #9: Design for Mobile Apps and Websites

real-world-accessibility-feature

Web designers and developers need techniques that work now while keeping an eye on what lies ahead. To do that, I’ve had one focus in every workshop I’ve taught over the past seven years: getting the best real world solutions for creating accessible websites and applications into the hands of developers and designers.

What do I even mean by real world? It’s very simple: Accessibility doesn’t and shouldn’t exist in a vacuum. The real world is messy. It isn’t black and white but every shade of grey in between. This applies to accessibility but also to our craft in general. We have to make compromises. We have to make choices. We have to change tactics mid-stream. And we have to have it finished yesterday.

And that’s why we focus on Real World Accessibility. You need to know what works now so that you can make informed decisions when you’re implementing modern web technologies. For the last two years, we’ve focused on Real World Accessibility for HTML5, CSS3 and ARIA—the workshop we’re bringing to Australia this month.

In preparation for the @feather Tour Down Under 2011 (I’m @feather on twitter) we crafted a page highlighting the content and details of what you’ll get. It isn’t the first HTML5 site/page we built, but we wanted to do something that created a unique design, was accessible, and gave us an opportunity to test out a few modern techniques for web design and development.

Every time we build something with HTML5, we get a chance to take a closer look at how accessible it is right now and we get a glimpse of what accessibility will be with new technologies.

HTML5 Semantics

I’m a fan of the new semantics that HTML5 brings us, for the most part. It opens new doors for us—authors around the world are excited to use the semantically sound elements that were introduced in HTML5.

And everyone knows that foundation of accessibility is semantics, right? Right.

So what happens when you combine a reasonably semantically rich language like HTML5 with browsers and assistive technology that was written before the semantics of HTML5 were even considered?

Nothing. And that’s the problem.

The advantages that the semantics of HTML5 bring to us are not really the boon to accessibility that they should be—yet. (To follow the development of which HTML5 elements are fully exposed by browsers and pass through to the accessibility APIs of different operating systems, be sure to check out HTML5accessibility.com.)

Accessibility continues to evolve in HTML5. There’s a team at the W3C dedicated to HTML5 Accessibility. And while accessibility for HTML5 continues to develop, I’m going to do my very best to ensure that what we’re doing for accessibility isn’t just about what will work in the future, but also about what works in the “here and now.” Why? Because we have “support” for HTML5 in browsers now. And that means that people are going to use it now. Which means it needs to be accessible now.

Here’s the real world situation with HTML5 accessibility as of this writing:

  1. We can use the new elements (article, section, aside, header, footer, nav to name a few) in our websites and apps right now.
  2. We can trick browsers that don’t natively understand those elements exist by using the HTML5 shiv. Yes it uses JavaScript and no, that’s not a reason not to use it. Yes, you need to consider the “JavaScript off” scenario, but we’ll talk more about that later.
  3. We must know that the semantics of HTML5 are NOT expressed or interpreted right now by existing assistive technologies. That’s okay—support will be coming, but it will take some time.
  4. While we’re waiting for support for emerging technologies such as HTML5, we need to find solutions that work now.

Web Content Accessibility Guidelines

I’m happy that we’ve moved on from WCAG 1.0, but I miss one of its hallmarks: the Interim Solutions Guideline. That told us to:

“Use interim solutions.

Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly.”

Let’s be clear: I don’t like the specific interim solutions that were advocated in WCAG 1.0. These checkpoints were all about “Until user agents” allow for X or have the functionality to do Y, use these techniques. User agents now do those things, so we don’t need to worry about them with WCAG 2.0. They’re so unimportant I’m not even going to mention them here.

But the idea behind using interim solutions was all about recognizing that certain techniques may not have full support in older assistive technologies or browsers and that we must think about those scenarios.

And that’s the case with HTML5 right now.

So what “Interim solutions” can we use with HTML5 to help assistive technology understand the semantics?

Using WAI-ARIA

ARIA (Accessible Rich Internet Applications) is a technology that is used to help specify programmatically what web a user interface component (or “widget”) is more clearly, so that assistive technologies can provide more meaning to its users.

It is often referred to as a “bridge technology” —in that it helps us bridge the gaps between the past, the present and the future. In short, if we have an existing legacy web application that uses older markup and coding practices, we can help make that more accessible by applying ARIA attributes to the markup without rewriting the entire application with more modern languages.

Here’s how ARIA helps.

Consider this Google Maps implementation: http://examples.furtherahead.com/aria/slider/index-3.html

real-world-accessibility-1

Note that we’ve used a custom set of controls on the map that allow for excellent keyboard accessibility. We’ve also implemented a custom slider control to replace the standard Google Maps control.

We don’t have a native slider element in HTML (at least not at present), so we built the slider with HTML, CSS and JavaScript such that it approximates the visual appearance and functionality of a slider control. The problem is that when we do so, we’re really creating a complex user interface component that is comprised of semantically meaningless divs, spans, images, links and buttons.

  1. For any complex user interface component, we need to know three basic pieces of information:
  2. What is this thing? (its role)
  3. What general characteristics does it have? (its properties)
  4. What can you tell me about it right now? (its state)

The whole is greater than the sum of its parts; taken together, those divs, spans, images and links create something more (a slider). ARIA lets us precisely specify the meaning of the whole so that assistive technologies can better understand the whole instead of breaking it down and trying to understand its individual components.

Traditionally we might have used markup something like this:

<a href="#"
      id="handle_zoomSlider">
<span>11</span>
</a>

The link gives us a focusable control that we can use for the slider’s “thumb” that will slide along the rail. The link text tells us the current zoom level (11), which is also displayed on the screen. We’d use a foreground or background image for the “rail” to make it look like a slider, and then we’d apply the appropriate JavaScript to allow us to  manipulate the thumb with the mouse and they keyboard.

To assistive technology though, this is just a link with some text in it. There’s no indication of what the link is about or what it does.

How can we make this better? We add some ARIA attributes:

<a href="#"
      id="handle_zoomSlider"
      role="slider"
      aria-orientation="vertical"
      aria-valuemin="0"
      aria-valuemax="17"
      aria-valuetext="14"
      aria-valuenow="14" >
<span>11</span>
</a>

The markup is fairly simple. We did a few things:

  1. indicated a role for the component (role="slider"),
  2. used aria-orientation="vertical" to specify that it is oriented vertically in the page, and,
  3. added several properties to that slider (aria-valuemin="0", aria-valuemax="17",aria-valuetext="14", and aria-valuenow="14").

When we use JavaScript to change the position of the thumb on the rail we also change the value of aria-valuenow and aria-valuetext to match the zoom level. The ARIA properties are updated, and provided we’re using the right pieces of assistive technology, we get the appropriate announcements or interaction with that interface component. A screen reader user, for example, will hear that the user interface component is a slider, and they will hear values being read out as the value changes in response to moving the thumb along the rail.

This is what ARIA gives us: the ability to provide better programmatic accessibility for complex user interface components. There’s a lot more detail to it, but that’s ARIA in a nutshell.

Now, then … I told you that to tell you this.

ARIA and HTML5

Remember we talked about the idea of Interim Solutions? That’s where ARIA and HTML5 come together.

ARIA has decent support in assistive technology. It isn’t perfect, but screen readers and magnifiers and other technologies are much further along in supporting ARIA than they are supporting HTML5. Why? Quite simply, even though ARIA is still “new,” it is older than HTML5. Assistive technology vendors have implemented support for certain parts of ARIA, and that support continues to grow.

Because of this level of support, we can add ARIA to give us some of the semantics that HTML5 should give us, but isn’t supported in or exposed to assistive technology just yet.

We use ARIA to complement the semantics of HTML5 in the sites that we build. We relaunched our accessibility focused site Simply Accessible in October of 2010 and defined a number of ARIA landmark roles that help give meaning where it can’t be delivered via HTML5 yet.

We added role=”main” to the main content on the page that is also marked up with HTML5’s <article> element. We used role=”complementary” on the <aside> element for the related content in the sidebar. And we used role=”navigation” on the <nav> elements at both the top and the bottom of the page.

See how it works? We are still using HTML5’s elements, but we’re supporting that with ARIA for those assistive technology and browser combinations that don’t “get” HTML5 yet.

We consider things in this order:

  1. What is the most semantic HTML5 that we can write to solve a problem?
  2. How can we convey as close to the same meaning with ARIA for technology that doesn’t understand HTML5?
  3. How can we convey as close to the same meaning for technologies that don’t understand either of HTML5 and ARIA?

Let’s wrap this up with one final example.

Figures in Web Pages

In a recent article Accessibility and HTML5 Block Links I talk about some of the issues that the block link structure creates with screen reading technology. In that article I use an HTML5 figure element to express the relationship between the image and the caption that is below it:

real-world-accessibility-2

<figure>
<img
      src="../blocklinksvoiceover-500-2.png"
      alt="Screenshot of block links with Voiceover on the Mac.">
<figcaption id="figcaption1">
<strong>Screenshot</strong>: We use block links on the promo page...
In other screen readers, parts of the link aren’t read at all.
</figcaption>
</figure>

This structure creates an explicit relationship where it didn’t exist before. The parent <figure> element contains a <figcaption> element with a sibling <img> element. This HTML5 structure formalizes what people have been doing for years — placing an image in the page and including a paragraph of text after it in the markup.

How does this work for a browser and assistive technology combination that doesn’t understand HTML5? Well, a browser that doesn’t understand an element just skips that element. So when we don’t have full HTML5 support, we fall back to the association by proximity: the image and the paragraph are siblings in the source code, so they must be related.

What can we do, though, for assistive technology that understands ARIA, but not <figure> and <figcaption>? We can create a programmatic association by adding the aria-describedby attribute:

<figure>
<img
      src="../blocklinksvoiceover-500-2.png"
      alt="Screenshot of block links with Voiceover on the Mac."
      aria-describedby="figcaption1">
<figcaption id="figcaption1">
      <strong>Screenshot</strong>: We use block links on the promo page...
      In other screen readers, parts of the link aren’t read at all.
</figcaption>
</figure>

Now there is a stronger association than just having the two pieces of content related by proximity, created by adding ARIA. The value of the aria-describedby attribute does just what you think it does: it contains an id value of the node in the page that describes the content. The detailed description of the <img> is provided by the node with the corresponding id—in this case, the <figcaption>.

What about the case where we have no HTML5 or ARIA support? We fall back to the age-old method of association by proximity: the image and the description are right next to each other in the code.

And that’s Real World Accessibility. It works now and will work better in the future.

Working through these kinds of scenarios is a pragmatic way to learn about Real World Accessibility, and these are exactly the kinds of scenarios we explore—in about as hands-on a way as you can imagine—in our full-day workshops. If you’re in Australia, you can register today, otherwise keep a look out for when we’re in your part of the world.

And in the meantime, let me know what you think about all this.

css-border-image

Editor’s Note: Images are used throughout this article to illustrate the effects achieved with border-image. To see this in action. and view the code, go to the demonstration page.

A feature that is new in CSS3, but not so new to browsers, is the border-image property. Border-image provides a method to add decorative borders to any element. With the border-image properties you can create decorative borders for elements, beyond simple rounded corners, with images of very small file size or even with gradients.

The border-image property allows you to take a small image, slice it virtually into nine sections, and place /spread the portions of your small image across a much larger element.

You can take an image and stretch it across a button or a whole page.

CSS3 border-image fig1

We’ve used the image on the left as a border-image for the div on the right, maintaining the corners, while stretching the center of the border-image to cover the entire div on the right.
CSS3 border-image fig2
In this second example, instead of stretching the middle of the border-image, we’ve repeated, slightly distorting the image if necessary to ensure we don’t have a broken image in supporting browsers.To ensure that the image is not ‘broken’, the width should be a multiple of the slice’s width. While we’ve repeated the top, bottom and sides, we’ve maintained the four corners, creating a stamp-like effect.

Next, we’ll cover how to take a background-image, virtually cut it up, and either repeat or stretch the image to cover the borders and background of our element.

The border-image is a shorthand property used to declare:

  border-image-source:
  border-image-slice:
  border-image-width:
  border-image-outset:
  border-image-repeat:

The syntax for the shorthand is:

 border-image: <source>
<slice {1,4}> / <width {1,4}> <outset> <repeat{1,2}>;

At this time, Opera, Firefox, Chrome and Safari all support the vendor prefixed border-image shorthand property but don’t support any of the longhand properties that make up the shorthand. So, while we’ll cover the various properties that define border images, you should always use the shorthand instead of the shorthand properties described below.

border-image-source:

The border-image-source, is the URL, gradient or data URI of the image you want to use as your border image. In the above examples, while the longhand property is NOT supported, it is as if we we had used

.gradientBox {
  border-image-source: url(gradient.png);
}
.stamp {
  border-image-source: url(stamp.gif);
}

Just as you can include gradients, base 64, gifs, jpegs, pngs, and even SVG images as background images, you can include all these image types as border images.

border-image-slice:

The border-image-slice property defines from one to four lengths that set the distance from each edge of the image marking the area that will be used to cut, or slice, up our border image.

The border-image-slice property values represent inward offsets from the top, right, bottom, and left (TRouBLe) edges respectively of the image. In effect, with the four lines you define, the browser divides the one border image into nine regions: four corners, four edges and a middle. The four corners maintain their exact size. The other five values can be stretched or repeated or a combo of the two (round), depending on the values of the other border-image properties.

CSS3 border-image fig3

The black lines in the images above delineate how our four defined slice lines cut up our border-image.

In our examples, we’ve sliced the image 30px in from each side for our gradient, and 8 pixels in from each side for our stamp.

In the above examples, while the longhand property is NOT supported, it is as if we we had used

.gradientBox {
  border-image-slice: 30 30 30 30;
}
.stamp {
  border-image-slice: 8 8 8 8;
}

or, since the values are repeated, like the TRBL of border or padding, we can use a single value for all four sides

.gradientBox {
  border-image-slice: 30;
}
.stamp {
  border-image-slice: 8;
}

Note we’ve used no length units. If you are setting the slice values in length, and the value will be interpreted as pixels, omit the units. If you are using percentage values, include the percent. In our example, we could also have used the following:

.gradientBox {
  border-image-slice: 30%;
}
.stamp {
  border-image-slice: 26.7%;
}

For bitmap images, the omitted values are interpolated as pixel values. For vector images (SVG), the values are coordinates. For percentages use the percent sign (%).

border-image-width:

The border-image-width property sets the width of the element’s border. If the border-image-width property is declared, it takes precedence over the border-width, if one is declared. If omitted and the border-width is omitted, the value defaults to the border-width default which is ‘medium’, or generally 3px.

This shorthand is NOT supported in Opera (build 1024 is the most recent one checked). Additionally, the value of auto is not supported in any browser. As such, it is often recommended to include border-width as a separate property. Declaring as part of the shorthand is as if we had declared:

.gradientBox {
  border-image-width: 30px 30px 30px 30px;
}
.stamp {
  border-image-width: 8px 8px 8px 8px;
}

or, since all the value are the same,

.gradientBox {
  border-image-width: 30px;
}
.stamp {
  border-image-width: 8px;
}

So far we have:

.gradientBox {
  border-image: url(gradient.png) 30 / 30px;
}
.stamp {
  border-image: url(stamp.gif) 8 / 8px;
}

Since including border-image-width in the shorthand currently makes Opera fail, it is recommended to exclude this property, and instead opt for including the CSS2 border-width value.

.gradientBox {
  border-width: 30px;
}
.stamp {
  border-width: 8px;
}

Having the border-image-width be the same width as the border-image-slice will create the best looking border image with no distortion. But, they don’t need to have the same values. The slice will be stretched (or contracted) to the width of the border-image-width if the values are not the same.

Remember the box model! As you increase the border-image-width, your element will grow larger.

border-image-outset

The border-image-outset property specifies the amount by which the border-image area extends beyond the border box on all four sides. It is not supported in any browsers, and makes the entire declaration fail, so, for now, don’t include it. The default value is 0.

border-image-repeat

The border-image-repeat property allows you to delineate how non-corner images (the sides and middle) are repeated and/or scaled. The first value is the top and bottom, the second value is the left and right sides. If the second value is omitted, all four sides will have the same value.

The specifications currently define four possible values, but only three are well supported. stretch means that the image should not be tiled, but rather stretched to fill the area. repeat means the image is tiled ( or repeated) to fill the area. If the area allocated for the repeating image is not exactly divisible by the width of the image, the last tiled image may be cut off. With round the image is tiled (repeated) to fill the area, with the image being scaled down, possibly losing its aspect ratio, but ensuring that the image is never cropped. Note that Webkit doesn’t support the round value, replacing it with repeat instead (which is better than failing, I guess).

The space value is not currently supported, but when supported, the border-image will be repeated as many times as can fully fit in the area provided, with the tiles evenly spaced, showing white space between the tiles if the width provided is not an exact multiple of the image size.

In our above examples, we used stretch for the gradient and round for the stamp. You will always want to stretch gradients, as repeating them creates harsh lines as one tile ends and the next begins. And, while it may seem to make sense to use repeat for the stamp, we have no way of knowing if the image is evenly divisible by the width of our design. The round does distort the image ever so slightly, but that is better than having the image cut off.

If we had used the inverse, the effect would be odd. While the top and bottom can use round, repeat or stretch, the left and right sides definitely need the stretch value:

CSS3 border-image fig4

CSS3 border-image fig5

Border-image shorthand

As mentioned earlier, no browser supports the longhand properties defined above, but Opera, Firefox, Chrome and Safari understand the prefixed shorthand border-image property. Now that we understand the components of the shorthand property, let’s put it all together.

The correct syntax is

border-image: <source>
<slice {1,4}> / <width {1,4}>  / <outset> <repeat{1,2}>;

Since outset is not currently supported, we can omit it:

border-image: <source>
<slice {1,4}> / <width {1,4}> <repeat{1,2}>;

Like all border-images, we’ve cut our gradient image into nine slices defined by the border-image-slice property. Generally, the slices are the same width as the border-width. And, since we have a gradient, we want to stretch the image, not tile it, so we don’t get harsh color transitions. As such our code is:

.gradientBox {
    border-image: url(gradient.png) 34 34 34 34 / 34px 34px 34px 34px stretch stretch;
}

which, with repeated values, we can narrow down to:

.gradientBox {
    border-image: url(gradient.png) 34  / 34px  stretch;
}

Since Opera doesn’t understand border-image-width when included in the shorthand, we include the border-width separately and then expand our declarations to include the various vendor prefixes:

.gradientBox {
   border-width: 34px;
  -moz-border-image: url(gradient.png) 34 / 34px  stretch;
  -webkit-border-image: url(gradient.png) 34 / 34px  stretch;
  -o-border-image: url(gradient.png) 34   stretch;
   border-image: url(gradient.png) 34 / 34px   stretch;
}

Similarly, our stamp effect includes the stamp image as the border-image-source, has borders that are eight pixels wide, has a repeating border which can’t have a partial image showing lest we break the design. We still have the Opera issue of border-width, and all supporting browsers still use the vendor prefix. As such, our code looks like this:

.stamp {
    border-width: 8px;
   -webkit-border-image: url(stamp.gif) 8 / 8px round;
   -moz-border-image: url(stamp.gif) 8 / 8px round;
   -o-border-image: url(stamp.gif) 8  round;
    border-image: url(stamp.gif) 8 / 8px  round;
    }

Resources

At this point, you hopefully have a good understanding of how to create a border image. There are a few tools to help you along:

Images are used throughout this article to illustrate the effects achieved with border-image. To see this in action. and view the code, go to the demonstration page.

539-html-email-boilerplate

Web developers often moan about having to support five mainstream browsers, a few mobile devices and quirky behavior in a certain applications. If you think we have it bad, spare a thought for those creating HTML emails. They must contend with:

Forget about stylesheets, floats, negative margins, positioning, background images, animated GIFs, PNGs or any other fun time-saving techniques. If you think it’s tough making a site work in IE6 today, HTML emails must be coded like it’s 1998. That means tables, inline styles and images.

Fortunately, Sean Powell has taken inspiration from Paul Irish’s HTML5 Boilerplate and created the HTML Email Boilerplate. It includes various fixes discovered by industry leaders such as Campaign Monitor and MailChimp to produce a bullet-proof email template which works in Outlook, GMail, Hotmail, Yahoo Mail and other popular clients.

Sean admits it’s not plug and play — you will need to get your hands dirty with coding — but it’s a great first step which solves many of the common problems experienced when developing HTML emails.

The HTML Email Boilerplate code includes two HTML files: one with commented instructions and one without which can be used as the basis of your email. It’s issued under the MIT License, is free and can be used for any commercial or non-commercial project.

What have you got to lose? Please let us know if you’ve tried the boilerplate and, more importantly, whether it worked in your email application.