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?

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.

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.

Try some demos: ARIA Live Regions Screen Reader Demo

And more resources…

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?

After writing an accessible form in XHTML and validating it with a PHP server side script & after that with a Mootools client-side script, I write today about a third way of approaching the subject – using future-to-come HTML5 (by saying that, I really hope to be able to use it waaaay before 2011).

The last MooTools version offers a validation plugin in the mootools-more package, that will help us solve our task. Basically we need to add some classes to out inputs, to reflect the type of validation we want. For our form, we need only name – mandatory, and email – mandatory + correct email formatting.

Tweet A good way to learn about accessibility is through examples and discussions. In this post I will try to translate the WCAG sometimes-hard-to-get rules into a copy-paste real contact form example.  You can check the test link, download the code and/or keep reading a bit more. As I mentioned before, contact forms are in [...]

When it comes to accessibility, every coder is a small guru. On the websites where I bid for projects everybody is an accessibility and usability expert (including myself, I admit).

Altough these rules exist for quite a while there are coders who find difficult to implement them – so I am trying to find here what are the tricks that you use in writing your code to make it accessible. For example, although writing semantic code helps (a lot !) it is not always enough. Some try to view their pages with CSS and images disabled, some don’t. Some of us have tricks that we do not want to share to other coders. Some of us share. We’re not all gurus, right? Someone has to start from somewhere.

So if you have something interesting to say, add your own rules here.