02-19 21:27

I was playing around with the current development version of WordPress (2.5 will be released in March) & had a nice surprise when I tried out the WYSIWYG editor. It’s about a year ago that I was last taking a serious look at the code they produced in response to Peter Krantz’s round-up over at “Standards Schmandards”.

Anyway it was nice to see that the indent button no longer uses the BLOCKQUOTE tag to achieve the desired styling, and that the alignment buttons have dispensed with the ‘align’ attribute.

It’s been a bugbear of mine that whilst the developers and designers of a site might be required (& also have a passionate desire) to work to standards, the content providers are being offered tools that makes all that effort redundant. In the case of these particular buttons they would have stopped a page from conforming with the Double-A WCAG 1.0 accessibility requirements and produced invalid XHTML 1.0 Strict code.

So well done moxiecode! Hopefully the other editors have already followed suit, or well do shortly.

02-19 21:27

A quick post before the Christmas break.

I recently came across Pearl Crescent Page Saver and I can see that it will be another useful tool to be used in 2008 when I’m working on template designs. Rather than just producing an image of what is visible on the screen, as happens with normal screenshot programs, it will include the whole of the web page. There’s also an option to run it from the command line, so it would be possible from a single command to create a batch file (or similar shell script)  to capture a range of templates that I’m working on.

I’ve found that it has been very useful for documenting the evolution of templates & I can see that it will be handy for comparing different versions (e.g. how a template looks as plain HTML/CSS pages and when it is integrated into a system, or to ensure that there have been no side effects when upgrading a look and feel).

Ideally there would be a similar tool for Internet Explorer as you would then be able to track the majority of the users - and it other browsers would be included it could then be used for cross-browser checking.

02-19 21:27

With all the (technical) media interest in the iPhone I decided it was worth taking a look at the iPod Touch to test out its new web browsing features. Other handheld devices and mobile phones have gone down the route of reducing a web page to fit the restricted environment of the screen, as can be seen in the screenshots for Internet Explorer Mobile. However there seems to be a trend for this paradigm of using a normal page but zooming in & out and scrolling around with your fingers. For example the new mobile operating system that Google have developed (Android) has similar features, as can be seen in this demonstration.

As I’ve been testing it out I have been struck by the similarities with the screen magnifier demonstration that I posted about before. There have been discussions in the past about the link between improving your search engine ranking and meeting accessibility requirements through the same techiniques (for example this article on A List Apart). We may find that the (possible) rise of the mobile web continues this trend. For example I’ve noticed that with the iPod I’ve wanted:

• layout and navigation conventions maintained - as with the screen magnifier you need to know where you are on a page and how to get to the content that interests you when you’ve zoomed in to see some detail
• space around links - ironically it’s harder to use some web sites that have been designed for standard handheld devices as you don’t have the same degree of accuracy if you’re pointing at a link with your finger rather than a stylus, this is similar to the experience desktop users will have with poor hand-eye co-ordination
• alternatives to scripting - the iPod Touch doesn’t support Flash at the moment so I’ve come to a shuddering halt with some sites that rely on this technology, so I could find something to see at the Watershed but not St George’s and couldn’t go into sysadmin mode with Google Analytics when I wanted to check up on clients’ websites

02-19 21:27

Continuing their series on accessibility technologies in action, Yahoo’s User Interface Blog has a video demonstrating ZoomText.  Most of the issues involve the visual aspects of a web page (as opposed to a screen reader where the code used to create the page is more important) - for instance consistency in layout (as the user might only see part of the page at a time, so needs to know which direction to scroll in).

I liked the fact that it hasn’t been through their marketing department - the user demonstrating the magnifier obviously has Google as her default home page.

02-19 21:27

Back in the old days (maybe in Web 0.9) Analog, the popular web analysis program, automatically added a ‘Valid HTML’ button at the bottom of each report page it produced. This was before the W3 Consortium took up the banner of validation, so the button was provided by a third-party site (webtechs.com). Either through a ‘clerical error’ or an invoice not paid the domain name being used to supply the image lapsed - and it was then taken over by someone else who decided to add in a completely inappropriate picture with the same filename.

If we move forward to the present day, then in Web 2.0 the idea of bringing in content from other sources is the distinct flavour of the month. In some cases this is still just images (for badges), but the norm is either to have RSS feeds (essentially bringing in HTML code, usually with no filtering of what is displayed) or JavaScript files (running programs in the end-user’s browser).

So you can imagine the following fictitious scenario. A well-known charity runs an extremely successful campaign using all the tricks of the social web trade. They’ve had fund-raising plugins downloaded & added to thousands of WordPress blogs; widgets on MySpace to email the key people concerned; badges appearing left, right & centre and RSS feeds being devoured. All being served from www.examplecharitycampign.org, which once the campaign is over is no longer required and the domain registration lapses.

In those circumstances it could be very easy for someone else to step in, and cause havoc - unsuspecting people could find themselves on what looks like a legitimate donation page, email addresses could be harvested if those were in forms, JavaScript programs not adding visible content to a page but still active (waiting for a browser security loophole, analysing what else is on the page, etc.), hidden links in RSS feeds to help with search engine ranking schemes, etc.

So it is important to plan what happens at the end of a campaign right from the start, rather than casually abandon it or start the process once it’s up and running. Amongst other things you need to decide whether you’re going to keep the domain name for the long term (in which case it needs to be treated like your organisation’s domain), where content is going to be made available (e.g. it could come from your organisation’s domain or from another ‘permanent’ address such as YouTube) and develop methods to try to keep in touch with your supporters/activists (not the easiest thing with viral marketing).

06-07 21:23

[…] Technically speaking… […]

02-28 13:44

Unfortunately the underlying technology used in most WYSIWYG editors makes it very easy to fall foul of these accessibility rules. The problem is the Indent button. It works fine if you use it on a list - making the list item that you’ve highlighted move in a level - but if you apply it to a paragraph then it will mark it up as a quote. That’s because the normal styling applied to a quote by your browser is to indent the text.

The relevant WCAG 1 checkpoint is:

3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation.

It’s a Priority 2 requirement, so is necessary for Double-A compliance.

Don’t indent with <blockquote>

So the first thing is probably to put some test content into your WYSIWYG editor and try the Indent button. Then look at the HTML code produced to see if it uses <blockquote>. If that is that case then you should only use that button for indenting lists.

The best alternative is to have an indent style added to your stylesheets and for that to be available as an option in your editor. Then you just have to highlight the text and select the style.

The next stop down is to have the style in your stylesheet but you have to go into the HTML code to say where you want to use it. Finally you can use the style attribute to put the formatting in directly.

In both cases you need to find the tag that surrounds the block of text that you want to indent. This is usually going to be a paragraph so you’re looking for <p>. If you’re armed with a class name from your stylesheet, say ‘indented’, then you want to change it to <p class=”indented”>, otherwise you’ll use something like <p style=”margin-left: 20px;”>.

Do mark up quotations

There are two relevant HTML tags - <blockquote> for blocks of text and <q> when it’s part of a block of text (i.e. a phrase within a sentence, etc.). You don’t need to go overboard though and mark up absolutely every piece of speech in your content.

If your normal browser is Internet Explorer and you’ve been using <q> in your content then you might be surprised by additional speech marks appearing in other browsers. Don’t worry that’s just the default behaviour. Internet Explorer (including IE7) doesn’t understand the tag so there’s no styling applied, some other browsers do and wrap the text up in speech marks. The best solution if you see this is to get your web team to remove this behaviour in the stylesheet so that it looks the same for everyone.

Don’t worry about &quot;

In your journeys through HTML you might have come across this strange notation, which looks like it’s something to do with quotes. It isn’t, so you can ignore it (or remain in your current blissful state).

It’s just used in the HTML code if you need a speech mark within, for example, alt text. The same character is used to enclose the alt text, so this is the route out of the potential confusion of speech marks inside speech marks. Your WYSIWYG editor should take care of these details for you though - you will still enter the ‘”‘ character in the dialog box.

Summary

• avoid using the Indent button if your editor converts it into the <blockquote> tag
• alternatively add a class (if it has been defined in your stylesheet) to the paragraph tag, or the style attribute (e.g. <p style=”margin-left: 20px”> …</p>)
• <blockquote> is for marking up blocks of text
• <q> is if you have a quote within a block of text
• some browsers wrap text marked with <q> in speech marks, Internet Explorer doesn’t – have them removed in your stylesheet for consistency
• don’t worry about &quot;

Tags: web-accessibility, editors, WYSIWYG

02-27 13:46

There are two checkpoints in the Web Content Accessibility Guidelines 1 (WCAG 1) directly covering links:

10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.

13.1 Clearly identify the target of each link.

Both of them are Priority 2, so you need to abide by them to meet Double-A compliance.

Making the links clear

Sighted users are able to scan through content and pick up the links by visual clues without having to wait for the content to be read out to them. The idea behind the second checkpoint is to help some screen readers that try to achieve the same result by extracting a list of all the links on a page. However since they are no longer in their original context then it is possible that they might not make sense.

There are two ways of solving this issue. The first way is to select the most appropriate text for the link - e.g. in the first sentence of this post I could have selected ‘checkpoints’ rather than ‘Web Content Accessibility Guidelines’, the latter works better out of context.

However this might not always be appropriate, as you don’t want to clutter your text with full titles (e.g. ‘in a previous article’ rather than the title of the article) or you might want more than one link for an item (e.g. a report might have two links, one to a Word file and the other to a PDF). So in this case you would use the second solution which is to use the ‘title’ attribute that’s found in the dialog box when inserting a link using your WYSIWYG editor.

This additional content is available to the screen reader in its list, and normally will pop up on the screen for other users when they move their mouse over the link. For example on the home page of this blog each post is linked to with the text ‘full article’ but if you put your mouse over the link then the article title is shown as well.

You’re definitely going to need the ‘title’ attribute if your writing/linking style is to pick out phrases in sentences and tease your readers.

Opening new windows

There’s a usability argument against creating new windows when clicking on a link that makes for a confusing user experience. The ‘power users’ take it all in their stride but for many others they might not notice that anything has changed until they come to use the back button or close the window. In accessibility terms the situation is worse. If someone can’t see the screen then it can be even more disorientating if they haven’t had any warning.

That’s the rationale behind checkpoint 10.1 - providing information for the user in advance of clicking the link. Following on from the discussion above then we need to make sure that this is included when the link is taken out of context by a screen reader. So you could use the link text itself, an icon in the link (obviously with appropriate alt text) or kept away from the screen design using the title attribute.

Gotcha

There’s a few small things to look out for with links:

• if you are opening new windows and your site should be producing XHTML, then I’ve noticed that some text editors include a ‘target’ option in their dialog box for adding a link which then produces the equivalent attribute in the A tag. Unfortunately that’s not allowed in XHTML, and your page must validate to meet Double-A compliance (checkpoint 3.2)
• the method for opening a new window if you’re using XHTML is to use JavaScript, and that means that you have to make sure the link still works for people who aren’t using it (or have it switched off), so something like: <a target=”_blank” href=”http://news.bbc.co.uk” > becomes < a href=”http://news.bbc.co.uk” onclick=”window.open(’http://news.bbc.co.uk’); return false;”>
• if the web address you’re putting into a link has an ‘&’ character in it then you should make sure that in the HTML for the page it’s shown as ‘&’, it’ll go back to ‘&’ when you click on the link or check it in the status bar of your browser - you don’t need to do this every time, just make sure that the system you’re using is dealing with this situation properly once

Summary

• Make sure that the text associate with the link is clear when taken in isolation, e.g. don’t just use ‘Read more’, either put more information in the text of the link or in the title attribute
• Let users know if clicking the link will open up in a new window - you could use an icon (with appropriate alt text), include it in the text of the link or put it in the title attribute (so that it’s not part of the screen design)
• If you’re opening new windows then check that your text editor is using the appropriate code for your site - if you’re using XHTML then it can’t use ‘target=…’ in the link but needs to use JavaScript instead, and the link also needs to work without JavaScript as well
• The first time that you use a web address with a ‘&’ you should check that the HTML for the resulting page converts it into a ‘&’

Tags: web-accessibility, editors, WYSIWYG

02-26 23:19

I’ve been keeping my eye on the figures showing the breakdown in browser market share on TheCounter.com. When I wrote in December Internet Explorer 7 (IE7) had just overtaken the combined versions of Firefox with 12% of users. Another two months have gone by and now in the figures for February it’s risen to 24% with the corresponding reduction being made for IE6 (down from 70% to 59%). The other browsers have remained more or less static - Firefox on 11-12%, Safari on 3% & IE5 on 1%.

Microsoft were reporting a higher market share a month ago (25% across all websites in the US compared to TheCounter.com’s 20%) as they notched up the 100 millionth IE7 installation. Given the vagaries of web statistics then it’s pretty much in the small ballpark.

An interesting aspect of the change in figures is that the increase is established (more or less) within the first few days of the month, and no significant variation thereafter. This is likely to change now that Windows Vista has been launched to the consumer market (on 31 January) as users upgrade or buy new machines (currently not shown in the operating system breakdown). So the stepped effect should be reduced in the future.

Tags: ie7 take-up, web browsers

02-16 18:43

I have to confess that Yahoo is not one of my usual haunts so I missed this excellent article the first time around - Graded Browser Support. It’s a very clear articulation & formalisation of something that many of us have been thinking about & trying to implement.

Essentially the idea is that you have (at least) 3 grades of web browser:

• an identified list of browsers (+ operating system) that will take full advantage of the capabilities of modern browsers and will be tested thoroughly (grade A)
• an identified list of browsers that will be able to access core functionality & content, but will only have a representative sample tested (grade C)
• the rest that will either take conform to current web standards like the grade A browsers or be able to function at the minimum level of the grade C, however there is no testing and no support (grade X)

Which browser gets put into which grade is going to depend on their market share for your audience (or the audience you desire). So in Yahoo’s case it’s approximately 96% in A, 3% in C & 1% in X.
It also takes up the idea of progressive enhancement of web pages rather than the more established idea of graceful degradation - i.e. that the first concern is about presenting the core content & functionality and then building on that, rather than putting in the bells & whistles and then trying to ensure older browsers didn’t trip up.

I must admit that each time I wrote ‘gracefully degrade’ in a proposal or documentation it felt like I was writing the next verse in a Tom Waits’ song (”We’re decomposing as we go”). So not only does the change in perspective make sense, but it will also make me feel better if I have to think about it on a Monday morning.

Tags: graded browser support, quality assurance, website management

02-15 13:16

There’s a buzz in the web developer community over the new Yahoo! Pipes service - it’s been flagged up on O’Reilly Radar and Read/Write Web.  It’s not as pretty as GoogleMaps but more significant in what it can allow you to do.

As the name suggests it is more to do with the plumbing behind the scenes than enhancing the user experience. However there are many exciting possibilities that it opens up - bringing content together from disparate websites and then combining them until you have something that could be feed into your own site.

The idea is borrowed from the pipes and filters functionality offered in Unix - take the information coming out of one process and feed it into another. Yahoo! Pipes applies that paradigm to the Internet. You start off with an information source (or a range of them), chain together a number of processes (combining, filtering, sorting, etc.) and then pump out an RSS feed at the other end. (There are options for entering data through the Yahoo! Pipes website & also viewing the results there, but at the moment I’m just concentrating on what providing content to your website.)

An example Pipe that they provide is the Aggregated News Alerts. This allows you to search for information from a range of sources (Bloglines, Google Blog Search, Technorati, etc.). The results are combined, sorted in date order & de-duplicated. It would be very easy to duplicate this Pipe, amend it so that the search term was already entered and therefore require no user interaction. If I wanted to include the results of that Pipe in this blog then I could use a WordPress plugin such as FeedWordPress or inlineRSS.

Now none of that is rocket science, it’s all something that a web developer could provide for you. However they’re not going to be able to do it with so little effort, adjust it so quickly to your changing requirements, nor offer an interface that’s so easy to use. Aggregating content has just become a commodity.

There are a few downsides to it all. The most notable at the moment is that it’s still in beta - and this is a real beta phase as I’ve had a few errors as I’ve been experimenting with creating new Pipes. In the longer term it could be the hardware and network resources made available to the service that could cause problems - the more successful it is the more data it needs to bring in, process & send out.
I’m not entirely clear where it fits into the business plan for Yahoo!, but I’m quite content to operate in ignorance on this one. Maybe it will end up mirroring Flickr with free and subscription accounts.
I would suspect that if it proves to be unsustainable then the code could easily be made available as open-source - a route that other corporates such as IBM have taken in the past. There doesn’t seem to be much that would be commercially sensitive, for example at the moment I would think there’s only the content analysis and location extraction that would use some of their core search technology.
The skills involved reduce the number of people who are likely to create their own Pipe, but it wouldn’t take a lot of effort to show someone with normal IT skills around an existing one in the visual editor so that they could make amendments on their own (e.g. adding another RSS feed, changing the number of items to include, the order they are sorted in, etc.).

I’m off to explore more …

Tags: yahoo pipes,, content aggregation

02-14 22:17

I’ve been keeping my eye on the figures showing the breakdown in browser market share on TheCounter.com. When I wrote in December Internet Explorer 7 (IE7) had just overtaken the combined versions  of Firefox with 12% of users. Another two months have gone by and now in the figures for February it’s risen to 24% with the corresponding reduction being made for IE6 (down from 70% to 59%). The other browsers have remained more or less static - Firefox on 11-12%, Safari on 3% & IE5 on 1%.

Microsoft were reporting a higher market share a month ago (25% across all websites in the US compared to TheCounter.com’s 20%) as they notched up the 100 millionth IE7 installation. Given the vagaries of web statistics then it’s pretty much in the small ballpark.

An interesting aspect of the change in figures is that the increase is established (more or less) within the first few days of the month, and no significant variation thereafter. This is likely to change now that Windows Vista has been launched to the consumer market (on 31 January) as users upgrade or buy new machines (currently not shown in the operating system breakdown). So the stepped effect should be reduced in the future.

Tags: ie7 take-up, web browsers

01-09 23:11

I’ve been struck again how often web designers go for the “baby bear” option when creating visuals for a new look & feel. We’re just going through the early stages of a templating job for a client so have been reviewing a set of visuals that have been produced, before we make them into static web pages & then integrate into a content management system.

Now there’s nothing wrong with trying to present a design in the best light, but it’s important that in showing everything so that it’s “just right” that you don’t lose sight of what will be the reality of the life of your website.

I think there are three main issues that come into play here. The first is that there are still remnants of print-based thinking around. Sometimes it’s not just the Photoshop files that are static, but also the thinking that’s behind it. When you’re working in print then you’re more in control of how someone is going to look at the design that you have produced, but with the web it doesn’t work that way. You have to take into account the different screen sizes, the possibility of the user resizing their browser window, the fact that the user can change the size of the text, the difference between text displaying on Macs and Windows, etc.

The second issue is the current trend for web publishing towards the content providers having more control in the process. In print media the tendency is for the content to be handed over to design specialists - either an internal department or an external agency. So on the web the resources required to reproduce the look & feel need to be taken into account.

Finally in the print world it appears that you have the two extremes of brand guidelines and a finished document. The guidelines are used over a long time period and make general comments about the look & feel of documents, whereas the finished document is very specific but once it has been printed it will remain unchanged. Design for websites on the other hand has to take on board the fact that it is specific and is used over a number of years. So the Photoshop mock-up that you have in front of you has to be able to accommodate a wide array of changes - new content being added that might be longer or shorter, topics to be added to the menu and possibly highlighted on the home page, etc.

Some of the things that it’s worth looking out for:

• How it will look on different size screens

  Quite often we’ll be presented with a page that’s laid out within a screenshot of a normal browser window. Whilst that can give a feel for how the design will appear on the user’s screen it won’t give you an idea of what happens when the user resizes their browser. Will it stretch to fit or add whitespace? How do those options look? What happens when the window is reduced? Is there a limit at which you’re not bothered how the page looks?

• Navigation that goes across the page

  With this particular project alarm bells sounded for me when I saw some horizontal navigation lining up with the end of the header content. It’s highly unlikely that that would happen in reality - it all depends on the number of elements in the navigation (which can change over time) and the width of the text (again the exact wording can change over time). Even if you were to go for a fixed width option (e.g. 8 items each 125 pixels wide, so that you know they’ll take up 1000 pixels in total) then that raises the question of what is determining the choice of items - your design or the information architecture?

• Screen elements that line up at the bottom

  If you take a look at the BBC News home page you’ll see that even there the text isn’t aligned with the bottom of the images. In fact I’d say that there’s a great deal of hidden skill working on the titles for the links (usually either they fit in one line or just a word over as normal text & two lines when used as the main articles) and the summary for the main articles (usually four lines). It’s possible to get a few elements to line up (for example we’ve made sure that the logo in the left column always appears at the bottom of the content on the Local Directgov site), but to do this with normal editable text & repeated a number of times on a page becomes unmanageable.

• What might be involved for your content providers

  Are the changes in text style easy to reproduce using your rich text editor or do you need some HTML knowledge? Are there pull-out quotes (if you take a look at the BBC News stories then you’ll see quotes or facts in grey boxes within the central column)? These take a bit more than applying a style to some text, so they’ll either need some training if added manually or programming if it’s to be automatic.

• The content that might appear

  Does the content shown just reflect the average size? What about shorter or longer pieces? Will there always be images (or no images)?

• Different users might have different views

  If you’re using a content management system then you’ll probably have at least the login/logout functionality to include and links into the admin system. If your website allows users to register, for example to gain access to member-only content or functionality, then how do the pages appear to members and non-members?

As with any computing project it’s better to spot issues sooner rather than later, as they can be easier to put right early on and therefore less costly. So push the designs that you’re reviewing around about. Find out what happens when they’re faced with circumstances that aren’t just right, because one thing that I can guarantee is that that will happen when they’re used on your website.

Tags: nptech, web design

12-14 10:28

Last week I’d posted about the new Askability site produced for the Children’s Society. When I first saw it I had a quick look at the HTML code on the page - it’s a bit of a habit of mine. I was disappointed to see that they were using tables to create the image and text for each symbol, but didn’t mention it as there might be good reason for breaking with accepted best practice in this particular situation.

[Technical background - You’re only supposed to use tables to display content that is table data, not for producing a desired layout. So for example they can be used for listing the temperatures and weather for a set of cities; the results of a poll; etc. In this case tables are being used to line the content up correctly, therefore only for layout purposes. Aligning content vertically is surprisingly difficult without tables and it appears that this is the problem that they have encountered.]

However I thought that it was time to make my concerns in a public arena after looking at their accessibility page for the site. Now I’m full of admiration for the work that has been done to produce this website, but I don’t think that it’s credible to claim Priority Level 3 (Triple-A) accessibility compliance as defined by the Web Content Accessibility Guidelines 1.

[More technical background - apart from the issue of using tables for layout purposes rather than for displaying table data, there are further checkpoints that refer to marking up the structure of content correctly - for headings, lists & quotes. All of these are required for Double-A compliance and there are pages where these requirements are not met.

Headings appear to be marked-up with a DIV tag, such as this news item for the death of Pinochet. On screen the heading is underlined, but the only addition is that the class ‘heading’ has been applied - always a sign that something is wrong. In fact there is nothing that they can do about this with their current implementation as it is not possible to have a table inside a heading since this would create invalid XHTML (another requirement for Double-A compliance).

Similarly the list of news categories should be marked-up as a list, but it is just a series of symbols. (Intriguingly the list of news stories at the next level down does use lists correctly, and no tables are used to create the symbols.)

The form in the About Us page is also missing LABEL tags to associate the radio buttons with the text labels. Again this is a checkpoint for Double-A compliance.]

In part I can see how they might have felt justified to make the claim as they state that it has been checked by Bobby. This is an automated accessibility auditing program, and I can well imagine that it didn’t find any errors. However this form of assessing a website has its limitations as a number of the requirements require an understanding of the content before a judgement can be passed. Usually these are flagged up as warnings and the user is advised to manually check the page to ensure that the points have been complied with. That would be the case with the headings and lists - after all the program would not be able to judge whether a piece of text is a heading or not.

So full marks for breaking new ground with site that addresses this particular audience, but I would prefer the accessibility statement to be more realistic and state that it was only Priority Level 1 (A) compliant and aiming to improve to at least Priority Level 2 (Double-A).

According to the December issue of the Headstar E-Access Bulletin (not yet on their website) the Department of Trade & Industry had also claimed that their website was Priority Level 3 (Triple-A) compliant. I notice that the accessbility statement has been changed to say that it is only Priority Level 1 (A) compliant and their undertaking an audit to find out what is necessary to achieve Priority Level 2 (Double-A) compliance.

It might not be easy to state publicly but at least the intended audience are aware of what they are likely to encounter when using the website and make the necessary adjustments. I don’t think we, as developers, designers and website managers, are helping the cause of e-accessibility if we misrepresent the effort required to maintain the highest levels of conformance.

Tags: web-accessibility, nptech

12-14 10:28

Language has a nasty habit of tripping people up when it comes to accessibility. It’s not something that happens that frequently on most sites, but it’s priority level 1 in the World Wide Web Consortium (W3C) guidelines. So if something slips through the net then you won’t even make A compliance let alone Double-A.

The relevant checkpoint in the Web Content Accessibility Guidelines (WCAG) is 4.1:

Clearly identify changes in the natural language of a document’s text and any text equivalents (e.g., captions).

The language for the page

So the first thing you might want to make sure is that a language has been specified for the page before thinking about your own content. After all there’s no real point in highlighting the exceptions if you haven’t said what is the rule.

When you view the HTML source for one of your content pages you search for ‘lang=’ - you could find this at the top attached to the < html > tag or it could be something like < meta content="xx-XX" http-equiv="content-language" / >. This shouldn’t be confused with Dublin Core metadata - if you’ve got something with “DC.language” then that’s what you’re looking at. If you can’t see a language definition page then check with your techies & get them to add it if it’s missing.

If you view the source code for this page then you’ll see that I’ve marked it up as “en-GB” right at the top. That’s the sort of thing you’re looking for.

Marking up changes

Unfortunately the standard settings for most rich text editors won’t be of much help in identifying language, to do this you will need to get into the HTML source for the content or convince your developers to add an option into the menu for you.

If you’re dealing with a few words within a sentence then you need to add a new tag around the appropriate text. So change your editor so that you’re looking at the HTML source. Track down the content that you need to mark as a different language and put in front of it < span lang="xx" > and then after it < /span > (the xx needs to be replaced with the appropriate language code that you can find about next). These tags should be placed immediately in front and after the text - there’s a thing in HTML about not having tags overlapping, so if you do this you don’t need to know anything more about it.

Remember that the guideline mentions “text equivalents” so if you’ve added an alt attribute for an image in another language then you need to put a < span > around the < img > tag.

If there’s a bigger chunk of text, such as a paragraph, then you can add the attribute ‘lang=”xx”‘ to the existing tag (again the xx needs to be replaced with the appropriate language code that you can find about next). So typically you might see the < p > tag and you’ll need to make it < p lang="fr" > for a paragraph of French. If there’s more than one paragraph then you do this on each < p > tag.

You can’t put a < span > around a < p > tag (so not < span lang="fr" >< p > … < /p >< /span >, but only the HTML pedants would be upset if you did something like < p > < span lang="fr"> … < /span > < /p >. That will be OK & would mean that you need only remember one solution.

Now you can see why I’d suggest that if you’re doing this often you should get something added to the toolbar to make it easy for you.

What language code should you be using?

The W3C have provided some advice for selecting a language code, which basically in this context boils down to:

• use the shortest language code that is appropriate (i.e. you don’t need to specify UK English unless there’s something that is specific to the region, just saying English will be fine)
• you can find the appropriate sections of code in the official language registry
• you’re most likely to either use the single language code (e.g. ‘es’ for Spanish, ‘fr’ for French) or the language code with region (e.g. ‘es-MX’ for Mexican Spanish, ‘es-ES’ for Spanish from Spain)

What should be marked up?

The answer to this sounds obvious - anything in a different language - but when it comes to the fine detail it can be a grey area. Should you mark up the names of people and places? I’d be intrigued to know what language code you’d use to get a screenreader to pronounce ‘Belvoir’ as ‘beaver’ (as in Belvoir Castle).

Bear in mind that it’s not an issue of pedantry (”Is ‘vice versa’ accepted as English or should it still be treated as Latin? Discuss.”) or cultural battles (although I could imagine the Academie Française insisting that Paris should not only be marked up as French, but French as spoken in France at that). The aim is to help screenreaders by giving them sufficient information to be able to pronounce the word correctly.

So try to be consistent if nothing else - make sure that other content providers for your site understand whatever rule that you come up with.

Summary

• Check that your page specifies the main language used in the content - this is different to specifying the language in Dublin Core metadata
• Mark up any changes in the language of your content
• Remember to think about the alt text for images as well
• The implementation of this guideline is pretty subjective - the main thing we’d recommend is being consistent & think what will be helpful for the user
• If you’re using other languages in the titles for your content then you should alert your developers - those pieces of text will be automatically dropped into menus or headings and they need to indicate the change of language
• Not an accessibility issue, but while we’re here - if you’re going to be using characters that aren’t in Western European languages then you probably also need to check with your developers as they might need to make some adjustments

Tags: web-accessibility, editors, WYSIWYG

12-14 10:28

The theme of this year’s International Day of Disabled Persons was e-accessibility. The United Nations commissioned Nomensa to undertake a global audit of websites - 100 leading sites taken from 20 countries - and the results have been published. Only 3 achieved the minimum standards for accessibility - the German Chancellor’s site, the Spanish Government site and the British Prime Minister’s site.

Tags: web accessibility

12-14 10:28

There’s a specialised human rights search engine that’s been launched - Hurisearch - involving most of the larger players in that field, and offering the opportunity for small organisations to join in.

Given the recent announcements about Google’s customised search offering I was anticipating that it would be built on the back of that technology. Instead it’s a service that has been developed over the last 3 years by FAST - an enterprise search company.

The timing of the two announcements though has the perennial development debate whirring away in the back of my mind - when is it better to use a ’shrink-wrapped’ solution or to ‘roll your own’?

In this case there’s an interesting fact tucked away in the Hurisearch documentation - they need $187,000 a year to keep the service going. Given the prominence of the FAST logo on the home page I’d suspect that there’s been a deal made, so the costs could be higher than that. How the overall price tag actually breaks down is another matter, but you’d expect that the development, maintenance and hosting costs to make up the majority of it.

Using Google Custom Search wouldn’t involve any monetary costs, but there would be a different set of issues to take on board:

• tucked away in the logo for the service is the word ‘beta’ - no service level guarantees at this stage (and it’s worth noting that their email service - Gmail - has been in beta testing since April 2004) and even when it is finally live you would expect it to be at a lower level than for a system that you are paying for
• no clear indication of how the search engine works - the natural assumption is that this sits on top of the normal Google search, but details about how this works aren’t generally available as, in common with other search engines, they’re fighting a constant battle against spam; the hope is that this extra dimension won’t detract from creating a good specialised search tool
• compromises on features - e.g. in addition to the content you see on a page Hurisearch will also look for metadata using a common standard (Dublin Core), currently this is not available in the Google offering

The issue of functional