Tag Archives: Accessibility

Possible new CSS features from Adobe

Inspired from the print world, people from Adobe and Microsoft are coming with new features that might (or might not) be embedded into future CSS specs. These new features – CSS Regions and CSS Exclusions – will allow text to flow into webpages pretty much like they do in newspapers and magazines.

You remember that the idea of text flowing into columns is another CSS3 proposal, CSS Multi-column Layout Module and web layouts imitating magazine layouts is CSS3 Paged Media Module

Let’s see some examples that Adobe implemented:

Content threads and shapes using CSS regions

Text could easily flow from one region to the other and we can also choose to imbricate regions or give them different widths, heights and positions in the layout (see picture below)

multiple content threads with CSS regions
content shaped like a heart with CSS regions
If you can set rectangular regions, why not come up with weird custom shapes?

Text will also flow from one region (shape in this case) to another.

The idea is super-cool and we waited for it for a while now, but I do wonder about its usability if we think about the way people are reading web content versus printed text (that might change the bottom-top L shaped reading order observed with eye tracking methods).

Content exclusion

text exclusion with CSS
The opposite idea is to exclude text from a certain region or regions. (rectangular or custom shape)

Possible real world implementations

adaptive design
Adobe came up with more complex examples (they work in their own version of WebKit based browser only since these features are still a draft and highly experimental).

Text can flow into custom shape areas and that will allow us create CSS accessible pie charts and complex layouts involving images and text that will behave well on devices with different screen sizes and resolutions.

Update: Stephen Hay talking about these features at Fronteers 2011

Stephen Hay | Go with the flow | Fronteers 2011 from Fronteers on Vimeo.

In this session, Stephen will introduce, discuss and give examples of CSS3 Regions.

Browsers have begun to introduce actual layout mechanisms like Flexible Box Layout and Grid/Template Layout. For this, we kneel humbly and are thankful. But while we’re at it, why settle for rudimentary layout tools when we can add content flow to the mix? CSS Regions attempts to bring the power of content flow from print to the Web. Think of Regions as Multi-column layout on adrenaline. Regions can be extremely powerful and useful on their own. When combined with other CSS3 modules they will give web designers and developers creative freedom which rivals that of printed media.

How screen readers speak a page with HTML5 and ARIA

After seeing how AT reads a content generated with CSS pseudo-elements I was thinking to move on to HTML5. And since there are a lot of people saying we should mix HTML5 with ARIA in order to increase the accessibility of a website, then why not test and see what happens?

A piece of code…

<header id="header" role="banner">  
    <div id="logo">Logo here</div>
    <nav role="navigation">
        <ul id="mainnav">........</ul>
<section id="content" role="main">  
    <h1>A level one heading here please</h1>
    <div role="application"><p>Here is where an application will be coded. </p></div> 
    <article role="article">             
            <h2 class="index-headings">Blog entry no 1</h2>
            <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit...</p>
    <article role="article">
            <h2 class="index-headings">Blog entry no 2</h2>
            <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit...</p>
<aside role="complementary">  
<footer id="footer"  role="contentinfo">This is where the footer will stay.</footer>     

This is the page containing both HTML5 elements:

  • header
  • nav
  • section
  • article
  • aside
  • footer

and ARIA roles (learn about ARIA):

  • role=”banner” – for the header element
  • role=”navigation” – for the nav element
  • role=”main” – attached to the section
  • role=”application” – in case I need to add a widget
  • role=”article” – for the article element
  • role=”complementary” – for the aside
  • role=”contentinfo” – for the footer

How NVDA, JAWS and Window Eyes read the HTML5-only version

Long story short, no screen reader noticed the HTML5 elements – as expected. They all behaved like those elements were simple DIVs and read the webpage accordingly.

How NVDA, JAWS and Window Eyes read the HTML5 + ARIA version

Much better this time, ARIA is doing wonders although I don’t understand why Window Eyes doesn’t even pronounce the existence of the headers…I am a newbie in this field so maybe I did something wrong? I do not want to do WE any injustice so let’s say the results are inconclusive regarding this software.

The difference

So what was the difference between the two versions? What ARIA brought from this point of view?

The banner area: role=”banner”

NVDA – “banner landmark logo here navigation landmark list with 4 items visited link home……. ”
JAWS – “banner landmark logo here navigation landmark list with 4 items visited link home……. ” At the beginning it also says that there are 8 landmarks, hurray!!!

The main area: role=”main”

NVDA – “main landmark heading level one …”
JAWS – “main landmark heading level one …”

The application area: role=”application”

NVDA – the application role was not read at all.
JAWS – “application landmark here is where….”

The articles: role=”article”

NVDA – the article was not mentioned in any way.
JAWS – “article landmark heading level….”

The sidebar: role=”complementary”

NVDA the sidebar was read like this: “complementary landmark heading level 2…..”
JAWS – “complementary landmark heading level 2…..”

The footer: role=”contentinfo”

– and the footer: “content info landmark this is where the….”
JAWS – “content info landmark this is where the….”

So far JAWS was the only one able to speak all the landmarks while NVDA missed the article and the application. Like I mentioned before, Window Eyes din not read ARIA elements but maybe it’s just me being a newbie…Your opinion is much appreciated, maybe together we can make it work 🙂

Check the Spanish version of this post:
Cómo leen los lectores de pantalla una página con HTML5 y ARIA

Testing the accessibility of the CSS generated content

This article is about how screen readers speak the content added with CSS pseudo-elements :before and :after (in CSS3 they are ::before and ::after).

I am trying to learn to use AT when developing websites and recently I saw that no matter how W3C wants us to use a certain CSS element, there will always be developers/designers who will try to push the limits of the specification.

While I do advise you to NOT use pseudo-elements to generate useful content (limit yourself to generating quotes or design elements), just in case somebody thinks that the cool resides in generating content with CSS because everything else is already old, let’s see how people using screen readers will “benefit” from the idea.

A piece of code…OK, maybe two…

The HTML is really simple, an innocent paragraph of text:

<h1>Example of content added with CSS pseudo-elements</h1>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit..and so on.</p>

and the CSS is also quite simple:

#content p:before {
content:"This is before the text, you can style it";
#content p:after{
content:"This is after the text";

Let’s hear voices

The video will show how NVDA, Jaws and Window Eyes read the page – I set NVDA to read at a lower rate in order for you to follow, but the other 2 are a bit faster.

The conclusion

There’s no need for me to tell you how bad the idea is, DON’T use these pseudo-elements for generating useful content, limit its use to generating quotes, breadcrumb icons, fluffy snowflakes or whatever. But keep it presentational in order for other people to have access to the useful stuff.

Check the Spanish version of this post:
Probando la accesibilidad del contenido generado por CSS

Useful 10 minutes of WAI ARIA

I would like to post here a selection of resources that might help you start using ARIA in your web applications or websites – although ARIA is still a draft. you can start using it and some AT will know how to read it.

Introduction to WAI ARIA

Written by Gez Lemon for Opera Developer, this article is the best post you can start with. You will understand why ARIA was created in the first place and you will understand some basic terms like: roles, states, properties, and my favorite, ARIA regions.

ARIA Roles 101

Now that you know the basics of ARIA, you can start implementing ARIA roles in your applications. A full list of the roles definitions can be seen here, at the W3C WAI ARIA 1.0 specs website.

Supported states and properties

Learning about ARIA properties is the next logical step, and the W3C WAI ARIA specifications are really helpful even if the first impression is that you read the Constitution or something 🙂

Try some demos: ARIA Live Regions Screen Reader Demo

A very useful video by Aaron Cannon (from cannonaccess.com) about using ARIA live regions in a correct way, the difference between aria-live=”polite” and aria-live=”rude” and how this whole thing works. You need to know that now aria-live=”rude” is not part of the specs anymore (it was really too rude) and we are left with “off”, “polite” and “assertive”.

You might wanna read ARIA and Progressive Enhancement written by Derek Featherstone for A List Apart because the small examples that you will find there will help you understand better the roles and the properties of ARIA.

If you wanna go back to reading the Constitution, WAI-ARIA 1.0 Authoring Practices – An author’s guide to understanding and implementing Accessible Rich Internet Applications is the next step, a page full of examples for you to learn from and best practices when it comes to implementing ARIA – pay special attention to Section 3: Keyboard and Structural Navigation, Section 4: Relationships and Section 5: Managing Dynamic Changes which is really really important.

Learn from examples

  • JQuery Widget Samples – a collection of common JQuery widgets made accessible with ARIA: sliders, progress bars, accordions, trees, carousels, tabs, etc….
  • jQuery-Accessible-RIA – adds some more ARIA examples: a form, a lightbox, tables, etc.

Update with more minutes of WAI ARIA

Aaron Gustafson also has a video with NVDA reading his now famous TabInterface.

TabInterface in Firefox using NVDA screenreader from Aaron Gustafson on Vimeo.

Check the Spanish version of this post:
10 minutos útiles de WAI ARIA

Good for you you’re coding accessible websites, but do you actually know any blind user?

What can you answer to your client when you try to explain that your code is semantic, crossbrowser and…accessible and your client asks you “Good for you you’re coding accessible websites, but do you actually know any blind user?” Meaning, why should someone care about how you code a site as long as table-based code is still ok and cheap?

Well…you may remain speechless. Cause I really don’t know any blind person nor a person using assistive technology altough I do know people that need to increase the font-size or lower the screen resolution to be able to read better. But even if I did not “see” one that should not mean they don’t exist – but how can this be proved?

Since assistive technologies do not leave traces, maybe a solution is to see who’s clicking the a+ a++ buttons. This surely will leave some trace, right?

So we started an experiment: we wrote a script counting the number of clicks performed on the a+ a++ buttons (I know it’s not very scientific – anyone can click – but we’re counting on the fact that our users do not know about the experiment and that at least a small percentage of the clicks will be genuine). Every click is counted and written in a file. We compare it to the Google Analytics stats and hope to obtain some information about this aspect of the sites.

After a month of comparing both methods we saw that the a+/ a++ navigation was clicked on a daily basis (even though one site was selling Christmas decorations !!! ) and most of the time a++ was the star ! Between 5% and 8% of the visitors were clicking these links and that is more than the number of clicks on “about” or “contact” links.

Now, the question that started this article remains – what is the best answer for the client asking  “Good for you you’re coding accessible websites, but do you actually know any blind user?”