Posts Tagged ‘html’

You’re trying to make your website accessible. Lovely stuff. But because screen reader technology is so bad, you need to add a bunch of inline span tags with the aria-label attribute on them so that you can add additional context, or, more usually, use some kind of hack to get around a screen reader bug.

This works well. However, it also splits the whole thing into separate groups. Consider the following example:

An annual subscription costs £20.00 per year.

Looks good. Except for VoiceOver on Mac and iOS, and probably other screen readers, too, will read out something like this:

Pound two zero zero zero

Oh no! It totally ignored the decimal point and now your user, if they are able to track the weird way it read out individual numbers, thinks that your product costs two thousand pounds. So, our old friend the Aria label is here to help.

Hurray! It now sounds like normal language. But it’s still confusing. Now the screenreader reads them out as three separate blocks. “An annual subscription.” “Twenty pounds, group.” “Per year.” The user has to navigate through all three of them even though it is one sentence.

To fix it, we can use the role attribute. Sometimes.

If we set it to role="text" it will work in WebKit. For example:

Now it will read out the entire sentence as one string, but still using the Aria label.

Is role=”text” a thing?

No. That’s the drawback. it was proposed to be included in the Aria spec, but nobody could agree on whether it should be a thing or not. So, it was left out. Therefore, it is not implemented everywhere.

It is implemented in WebKit, so will fix the problem on Chrome, iOS, etc. But it won’t fix it in some other browsers. And, you might get pulled up by linting tools and validators because it is not part of any formal specification.

Where can I put it?

Anywhere you like given that it is a made up attribute.

But there are some things to be cautious of. It should only go on a block of text where you do not mind losing any of the context inside of it. If you have an element inside the paragraph, for example, that should be treated as a separate group, then leave it off.

It shouldn’t on headings because you don’t want to lose the context. Instead, put a span tag inside the heading with it on.

Also, you need to ensure you are using the aria-label attribute for anything inside. Normally, you can use an abbr tag with a title attribute and the screen reader will read out the title. However, if you wrap it in a role="text", this will only work if you use an aria-label instead/as well as the title attribute.

When you paste a link into Facebook or other social networks (which in theory you could use) it generates a preview of the website including a title, image and description.

Webmasters actually have the power to suggest content for these items. This is something I recently implemented on the Leeds Restaurant Guide.

For example, the page is structured with the site name in the title and various images on the pages. However, when you post it into Facebook, it is pretty obvious to a human what information you actually want in there. You want the name of the restaurant and the image of the restaurant itself.

To suggest to the client what information I think would be best in there, I added some meta tags based on the Open Graph Protocol. For example, here is an example from Bibis.

This provides helpful information to the client, usually Facebook, as to what information it should display where, making your site more sharable. Sites like BuzzFeed are all other these sorts of tags – just view their source code to see. This is why they are always so well presented and perhaps one of the reasons why they are so successful.

If you’re using HTML5, you may well have come across templates, which are a way to create reusable code clocks. They can be used in conjunction with the Shadow DOM to create more semantic markup while still adding all the additional goodies in terms of additional CSS and HTML that you would like.

For example, lets say we want to put an email address in a fancy box into a website. The old horrible way of doing it is something like this:

Look at all that stuff we do not need. Semantically we do not need all those divs. Crawlers don’t need to seem them. Neither do accessibility tools. It would be way nicer if we could mark the page up like this:

<div id="email">john@example.com</div>

Turns out we can! All we need is a little help from templates and the shadow DOM. Lets work from that markup, and put the additional markup into a template tag.

You will notice that this is basically the same code as we started out with, except now it is in a template tag, and instead of having the email address in there, there is a >content> tag. This acts as a placeholder that the contents of the div will be put into when we combine it all together.

This allows us to add all the additional styling that we had initially, but thanks to the shadow DOM we are able to eliminate a lot of the additional markup in the page itself that made very little sense semantically.

Recently I spent a good twenty minutes tearing my hair out over a JavaScript unit test I was trying to write. The answer turned out to be a difference in the way our Mocha-based DOM differs from how it would running JavaScript in a browser.

For example, let’s say you have a select field.

In a browser, the top option would be selected by default, so if you had the following code:

jQuery('#test').val();

It would output a blank value as you would expect. However, run this in Mocha and you will get an undefined or a null. The reason is Mocha doesn’t select the top option by default unless you manually specify it to. So your HTML would have to look like:

In which case, it would then return the value as it should.

These days, we’re all trying to do very clever things in the browser, that take up heaps of system resources. Often, your application will be doing so much that the system can barely cope – and with JavaScript being a single thread language, heavy processing can tie the UI up and make the user think the page has crashed.

Enter web workers – a background process that essentially allows you to do concurrent JavaScript. You can create a background process from a script, and then send messages back and forth between it and the page, ensuring you don’t tie up the UI.

Well, sort of. AJaxian wrote a very interesting post about display: table CSS and how after all this time of moving away from table layouts to CSS layouts we are now putting it all into CSS so we can essentially use table layouts again. It’s about time.

We’ve all spent years moving over to CSS layouts and support has gradually been getting better but we still can’t do a lot of basic stuff that you can do with tables without lots of hacks and crazy implementations that shouldn’t be there.

Take for example creating columns. We’re still using faux background images to create the column backgrounds and then putting a clear: both div below everything which shouldn’t really be there in semantic mark-up because it has no meaning, it’s just a CSS hack. These are things we could do with ease using tables.

While I’m on the subject there is also an interesting article on TJK Design about building layouts without using floats, the site being built entirely using lists which degrades beautifully if you turn off CSS.