Construction Project Management Courses
By Joann
An industry that continues to grow and shows only a little sign of slowing, the construction industry competitive world are in need of construction professionals who are equipped with skills and the know-how to effectively carry out the assigned job. So, if you are planning to choose a career in the field of construction management, might as well take up a program that will help you excel, like the construction project management courses offered in some of the schools. The construction project management courses provide construction professionals practical knowledge and expertise, which are exactly necessary to do your job.

The innovative and timely series of Construction Project Management courses are designed to develop the knowledge base of those working as project managers and project personnel, and to those who show interests to enter the field of construction management, whether for the principal or for service providers like consultants or contractors. The course focuses on basic principles across the breadth of the project management body of knowledge, and covers the key concepts in managing a project right from the start to final close-out.

The topics may include, but not limited to construction accounting, acquisitions, developments, estimation, plan reading, field project management, real estate law, bidding, scheduling, and construction safety. To obtain certificate of completion, students must successfully complete eight intensive courses. However, if you do not plan to pursue a certificate, you may possibly take individual classes. Additionally, all construction project management courses provide Continuing Education Units or CEUs.

The Core Courses of Construction Project Management Program may include but not limited to:

Construction Accounting this course reviews accounting theory, providing an understanding of the terminology of accounting. Payroll accounting focuses on workers compensation insurance, cost allocation and control. There is also other subjects that include types of businesses and organizations, lien law, construction cost control, progress payments and sub-contractor invoices, back charges, cash flow and cost of sales.

This Financing Real Estate Acquisitions course focuses on the nature of development projects, sources of funds, mortgages, payment and construction loan processing, and administration for both portfolio and for the sale projects.

The Estimation course provides cost estimating with emphasis on quantity survey and pricing. This Plan Reading course provides a survey of the fundamentals of Construction Math and plan reading. The Field Project management is one of the construction project management courses, which helps you become a successful project manager by learning the basic principles and responsibilities of construction process. You will also learn how to identify and manage the important components of project planning, budgeting and scheduling, resource allocation, legal requirements and ethical considerations, construction safety, and project supervision.

Real Estate Law (Law for Construction)this law provides an overview of the legal system such as contractor license law, contract laws, real estate law, mechanic liens, as well as basic contract principles and responsibilities.

Bidding and Scheduling this is one of the important construction

60 Hot To Touch Accessible Web Design Tips by Jim Byrne - published in paperback today
New book by Jim Byrne launched: 60 hot to touch Accessible Web Design tips - the tips no web developer can live without!. Now available in paperback. It takes a different approach to the standard big and heavy web technique tomes currently available - this one offers light bytes for easy digestion. It contains 60 easy to understand, practical tips you can put to good use when developing your next website.
New Website launched: Accessible Web Design Services Glasgow
Former Making Connections Unit Director and Web accessibility specialist Jim Byrne has launched his new business website with the aim of helping organisations: Comply with Disability Discrimination legislation. Reach the largest potential audience - via an accessible, usable website. Access tailored training and support to maintain websites in the most efficient and accessible way.
Seminar: The Disability Discrimination Act (DDA) and UK websites
A two hour seminar: Date: 25th May 9.45am - 12am. Book early to avoid disappointment. Venue: The Volunteer Centre, 84 Miller Street, Glasgow G1 1DT Cost: 39UK pounds per person. Facilitator: Jim Byrne email: ddaseminar@jimbyrne.co.uk Does your website comply with the DDA? Book your place on this seminar to explore the issues and find out what you need to know about the DDA and UK websites. This seminar is aimed at those individuals responsible for the creation, or management, of an organisation’s website. By the end of the seminar you will have answers to the following questions: Is your organisation’s website covered by the DDA? What should you do if someone complains that they can’t access your website? Who is responsible for making a website accessible, the site developer or your organisation? How is Web accessibility measured? Are there standards that websites should meet? How do you ensure you are not discriminating against a section of your audience? Where can you find help to make sure your website is accessible and complies with legislation? You will take away with you: Useful resources relating to all aspects of the course, a list of resources related to the DDA and accessible web design and information about how to get help to ensure your website is accessible. Jim Byrne & Associates - Web Accessibility Specialists "Organisations that offer goods and services over the Web already have a legal duty to make their websites accessible to disabled people." Bert Massie, DRC Chairman, speaking at the launch of the investigation into Web Accessibility April 14th 2004. Jim Byrne and Associates provide a full Web Design, Development and Training Service with a particular emphasis on accessibility and usability. Contact us now to book at place on the course: Jim Byrne and Associates, Accessible Web Design, Development and Training 23 Glasgow Street, Glasgow, G12 8JW Tel: 0141 334 1650 Mobile: 0781 0098 119 email: ddaseminar@jimbyrne.co.uk
Jim Byrne leaves Glasgow Caledonian University - now providing Web accessibility services
Jim Byrne leaves Glasgow Caledonian University - to provide accessibility web design, development and training services. I have been working within Glasgow Caledonian University since 1996, running the Making Connections Unit as a non-profit organisation providing advice, support and services to organisations interested in publishing accessible information on the web. In the last year I have worked as the University Web Accessibility Project Manager, providing training and consultancy to the web team (and external organisations) and working towards ensuring university websites are accessible to student and staff. However, all good things must come to an end, the University Web Team are now all 'web accessibility disciples' and I have decided it is time to move on. I have left the university and set up my own Web Consultancy to provide web design, web development and accessible web design training to organisations in the public and private sector. My sincere thanks to everyone in the University who has given me advice, bought me a coffee, and supported me in my endeavours to promote web accessibiltiy over the years. I'm now in the market for consultancy jobs and contracts related to accessible web design and development - or if you prefer - just web design and development - but with the accessibility part thrown in as part of the package. I'd appreciate it if you keep my name in mind if you meet anyone who is thinking about web development or training - even if they have never heard of the term, web accessibility. Th following information is my 'pitch for work' and information about the services and skills I can offer to organisations in the market for web design, web development and training. Contact me now if you would like to speak to me about any of the following. Training I can travel throughout the UK and Europe to provide training 'in-house'. Introductory courses The easy way to learning and understand HTML to create accessible web pages. The easy way to learn and understand Cascading Style Sheets for flexible presentation of web content. Disability Discrimination Act (DDA) and UK websites seminar. A half-day seminar exploring your obligations in relation to the DDA (and SENDA if you are within the education sector). The following courses are suitable to technical and non-technical individuals. Introduction to accessible web design - a one day introductory course. Accessible Web Design in practice. A comprehensive 2 day course that gives a solid grounding in the skills and 'mindset' required to create and manage accessible websites. This course has proved very popular in the past and the feedback has always be excellent. Customised training I can create training courses customised to your needs. If the exmaple above are not what you are looking for please get in touch to discuss how I can create a course to meet your requirements. I have over a decade of experience providing training to local government, higher education, and the voluntary sector. I have also provided training to private sector companies and corporate organisations. Feedback has always been extremely positive. Web Accessibility Services Alternative approaches to Website Accessibility Auditing In my experience just commissioning an accessibility audit isn't always the best approach, as developers need to have the skills and motivation to follow up on any recommendations. It's easy to put the report on a shelf somewhere and forget about it. An alternative approach I have used successfully in the past is to combine a half-day training with a half-day 'live access audit', testing your site against W3C WCAG guidelines with the web team and managers present for discussion and questions. This can be enjoyable as well as educational and a very effective way of getting developers on board. With this unique 'live audit' service you get instant feedback on the strengths and weaknesses of your site - so it is a more 'immediate' and memorable way to test and improve your site. This approach helps me to differentiate myself from other organisations providing web accessibility auditing services. In a 'live audit' there is nowhere for the auditor to hide. Auditing a site in-house, and discussing it with web developers means you have to be confident you know what you are talking about. The above approach can be combined with the more traditional accessibility audit and reporting; providing you with a 30 to 50 page report with screen shots, code examples, and recommendations. Examples of issues addressed when auditing a website Colour and colour contrast (e.g., checking for colour blindness access, visual impairment) The unit of measurement used to set the size of text. The font used for text on the site. Labeling for non-text content. Whether the HTML is coded correctly. Accessibility of forms. Consistency and usability of site navigation. The accessibility of any Javascript used. The flexibility of the design, checking whether it will work on all browsers. Accessibility of link text. Accessibility to people with different impairments. The foregoing is not an exhaustive list, but it gives an idea of the range of work undertaken. Working with your team I can work collaboratively with your existing developer or undertake periodic audits and reports after work has been done. For example: to help ensure that the 'front-end' of you web based organisation database is accessible. This would include ensuring that search and report forms are accessible to screen reader users or people with a motor impairment. Also that the database design can be used by someone who has Dyslexia - (as they may need to change contrast to suit their own needs). Website design will meet the W3C Web Content Accessibility Guidelines to an agreed level. I can provide advice and support to your team by passing on knowledge and techniques relating to accessible website design (and the W3C Guidelines). This can be done informally or formally as part of a training course. The aim is to ensure that issues are discovered early in a project, so that they do not need to be re-visited at a later date. The service can be customising to meet your needs You may want to arrange different pieces of work as distinct jobs for an agreed price, or prefer ongoing work at an hourly rate, or agree a certain number of hours over a set period of time. Accessible Content Management System (CMS) My accessible CMS, QnECMs (Quick & Easy Content Management System), as used on this site, the Guild of Accessible Web Designers website and many others, is now available for sale at http://www.qnecms.co.uk It is suitable for small businesses, individuals and colleges and it's main strength, apart from having an accessible standards based administration interface - is that it is easy to use. It is also affordable, and it can be re-branded for developers to offer to their own clients. That's all for now - thanks. Jim Byrne Contact me now if you would like to speak to me about any of the above.
Accessible Web Design in Practice Training Course
There are still a few places left on the next Making Connections Unit, Accessible Web Design in Practice training course on the 9th and 10th of December. This a 2 day course being run in Glasgow Caledonian University Library in the Centre of Glasgow; the venue is close to both main Glasgow bus and train stations. Register your interest in the course by filling in the booking form. About the course This course is not about creating unattractive 'text only' pages; accessible design is about designing for disabled people and non-disabled people. The training combines off-line discussion and learning, with online experience and examples - including hands-on experience of surfing websites with text browser, a screen reader and using the keyboard only. Hands-on activities include using online checking tools to check the validity and accessibility of websites - and interpreting the results. The first day of the course builds an understanding of what is meant by accessible web design, and give a 'framework for thinking' - that provides a context for the topics covered in day two. I consider this an important aspect of the course; but it is not addressed, as far as I am aware, on any of the other accessible web design courses. This first day also gives and understanding of what HTML is, how it should be used, and makes makes it accessible or not accessible. The training is aimed at helping publishers manage their web content in a more efficient and flexible manner; accessible web design is about more than learning individual HTML techniques (although you learn the techniques as well). Accessible web design is about understanding how to manage and publish web content in the most flexible way - cutting down the work web publishers have to do to reach their widest possible audience. The second days is more 'topic' based, i.e. how do you make PDFs, web text, forms accessible, making pages accessible for people with particular impairments, and so on. The course is taught in a very 'interactive' manner - questions and discussion are the basis of the learning - with frequent reviews of what has been learned. In addition to the training itself, all course participants will take away extensive notes and articles for all of the topics (listed on the course outline at http://www.mcu.org.uk/services/training.html) for both days. About The Making Connections Unit The Making Connections Unit, set up by Jim Byrne and David Donald in 1996, has been a pioneer in the area of Internet accessibility. It is based in Glasgow Caledonian University and provides web accessibility consultancy and services to nation and local government, as well as the voluntary sector, not for profit and private sector. About your tutor Jim Byrne Jim is a recognised expert in the field of accessible web design and has a thorough awareness of practice and policy issues. A former Disability Information and Training Officer, he has extensive experience delivering staff development and training programmes within the public, private and voluntary sector. He has written and spoken widely on the subject of accessible Web design, including publications for The Scottish Accessible Information Forum, and articles for The Times Higher Education supplement and a host of online magazines. He has also spoken about the subject of accessible web design on radio and television. In 2001 he was identified as one of Scotland's 'movers and shakers in e-commerce in Scotland' for his work in the area of Web accessibility (NB Magazine, June, 2001). Jim has been using and programming computers on a daily basis since 1979, and learning about how to design accessible websites since 1996. Register for the course now at http://www.mcu.org.uk/services/bookingform.html Please don't hesitate to get back in touch if you would like further information about the course. Please pass this information on to other people you know who are interested in accessible web design.
Mozilla Accessibility
"Firefox and Mozilla Application Suite offer several preferences that may be helpful specially for people with disabilities..." "Aaron Leventhal, leader of Mozilla Accessibility provides us an insight of what Mozilla has to offer to people with disabilities and where Mozilla as a project is heading. " Read more about Mozilla Aaccessibility and an interview with Aaron Leventhal on the Mozilla Links newsletter. Reading the Aaron Leventhal interview I discovered The Mozilla Accessibility Project - which I had never seen before.
The Flash Satay method to embed flash in your pages and support standards
This weeks tip: Use the Flash Satay method to embed flash in your pages and support standards The standard way to embed flash within a web page is to use the object element; the W3C tell us that the object element is an, 'all-purpose solution to generic object inclusion'. So that's fine and handy - however, the object element is not supported by all web browsers. Developers have tried to work around this deficiency by adding the non-standard (but working) embed tag into their markup - effectively repeating all the necessary attributes in each tag. Using the embed tag means that pages will no longer validate - a situation which makes developers who pride themselves on their adherence to standards rather uncomfortable. During a discussion about this issue on the Guild of Accessible Web Designers mailing list, I was alerted to an article by Drew Mclellan who addresses this very problem. Drew provides a solution that ensures flash works in many more browsers without failing validation tests, a solution he calls the, 'Flash Satay method'. For the full story and his detailed solution of how to embed flash in your pages and keep them standard compliant, read Drew's excellent article at http://www.alistapart.com/articles/flashsatay/ Links: Guild of Accessible Web Designrs Flash Satay Article W3C information about object element
Accessible Web Design in Practice Training Course
There are still a few places left on the next Making Connections Unit, Accessible Web Design in Practice training course on the 28th and 29th of October. This a 2 day course being run in Glasgow Caledonian University Library in the Centre of Glasgow; the venue is close to both main Glasgow bus and train stations. Register your interest in the course by filling in the booking form. About the course This course is not about creating unattractive 'text only' pages; accessible design is about designing for disabled people and non-disabled people. The training combines off-line discussion and learning, with online experience and examples - including hands-on experience of surfing websites with text browser, a screen reader and using the keyboard only. Hands-on activities include using online checking tools to check the validity and accessibility of websites - and interpreting the results. The first day of the course builds an understanding of what is meant by accessible web design, and give a 'framework for thinking' - that provides a context for the topics covered in day two. I consider this an important aspect of the course; but it is not addressed, as far as I am aware, on any of the other accessible web design courses. This first day also gives and understanding of what HTML is, how it should be used, and makes makes it accessible or not accessible. The training is aimed at helping publishers manage their web content in a more efficient and flexible manner; accessible web design is about more than learning individual HTML techniques (although you learn the techniques as well). Accessible web design is about understanding how to manage and publish web content in the most flexible way - cutting down the work web publishers have to do to reach their widest possible audience. The second days is more 'topic' based, i.e. how do you make PDFs, web text, forms accessible, making pages accessible for people with particular impairments, and so on. The course is taught in a very 'interactive' manner - questions and discussion are the basis of the learning - with frequent reviews of what has been learned. In addition to the training itself, all course participants will take away extensive notes and articles for all of the topics (listed on the course outline at http://www.mcu.org.uk/services/training.html) for both days. About The Making Connections Unit The Making Connections Unit, set up by Jim Byrne and David Donald in 1996, has been a pioneer in the area of Internet accessibility. It is based in Glasgow Caledonian University and provides web accessibility consultancy and services to nation and local government, as well as the voluntary sector, not for profit and private sector. About your tutor Jim Byrne Jim is a recognised expert in the field of accessible web design and has a thorough awareness of practice and policy issues. A former Disability Information and Training Officer, he has extensive experience delivering staff development and training programmes within the public, private and voluntary sector. He has written and spoken widely on the subject of accessible Web design, including publications for The Scottish Accessible Information Forum, and articles for The Times Higher Education supplement and a host of online magazines. He has also spoken about the subject of accessible web design on radio and television. In 2001 he was identified as one of Scotland's 'movers and shakers in e-commerce in Scotland' for his work in the area of Web accessibility (NB Magazine, June, 2001). Jim has been using and programming computers on a daily basis since 1979, and learning about how to design accessible websites since 1996. Register for the course now at http://www.mcu.org.uk/services/bookingform.html Please don't hesitate to get back in touch if you would like further information about the course. Please pass this information on to other people you know who are interested in accessible web design.
GAWDS new web design
The Guild of Accessible Web Designers (GAWDS) haver re-designed their website. The design was created by Phil Treble, who won the design competition as part of the launch of the Guild.
How to make your pages validate when they include urls with ampersands in them.
At some point you will run your web page through the W3C validator and get the error, "unknown entity section"; this is due to the presence of ampersands (&'s) in page link urls. The validator assumes that this is an error because it expects an ampersand to be the beginning of an entity. I had this very problem myself when creating the weblog links for my own CMS. For me the solution was simple; I just get the CMS script to turn all ampersands into their equivalent entities. Unfortunately it is slightly more work to manually replace all ampersands in a page, but if you want your page to validate it is a chore you will need to attend to: For all urls in web pages that contain ampersands, i.e., replace each ampersand (&) in urls embedded within your pages, with the equivalent entity &. Another validation problems solved.
Develop your sites for a standard compliant browser first then modify for IE/Win
This weeks tip: develop your sites for a standard compliant browser first, and then add workarounds for Microsoft Internet Explorer on Windows (MSIE/Win). I picked up this tip while reading through, 'Throwing Tables Out the Window', by Douglas Bowman; an article about how he used CSS to re-do the layout of the Microsoft home page. Instead of concentrating on getting your design to work in Internet Explorer on the PC (the most popular web browser), he recommends that you do all your initial work and testing using a more standards compliant browser. This approach will cut the time you have to spend creating the inevitable workarounds required once you discover that your design falls apart in every other browser apart from yours. :-) The thrust of the argument: It is easier to tweak a standards compliant website to work in the Internet Explorer, than it is to fix a site optimized for IE/Win to work in more standard compliant browsers. Throwing Tables Out the Window by Douglas Bowman:
How to make client-side image maps accessible.
Although client-side images are preferred over server-side image maps - as equivelent text can be provided for each image map 'hot-spot' - server-side image maps are sometimes necessary, e.g. when the active regions of a client-side image map cannot be easily defined using an available geographic shape. In such cases the answer is to provide redundant text links relating to each link provided by the server side image map. The following markup example is typical of the code used to reference a server side image map. <a href="/cgi-bin/mymap.map"> <img ismap src="imagemap.gif" > </a> The web pages accessed by the clicking the mage map in the above example would completely hidden to someone using a screen reader or a text-only web browser, as there is no alternative way of accessing the links provided. An example of the server side image with alt attribute added and an alternative set of links to the same content: <a href="/cgi-bin/mymap.map"> <img ismap src="imagemap.gif" alt="Alternative text links are provided at the foot of the page."> </a> You then make the following links available at the foot of the page, <p><a href="about.html">About Us</a> | <a href="research.html">Research</a> </p> As you can see in the example above the alt attribute provided information about where to find the text based links. The alternative text based links provide at the bottom of the page imply that the image map has two hot-spots, one to find information about the organisation and another for information related to research.
Oralux: Audio GNU/Linux Distro for Vision Impaired Persons
Here is an interesting Linux Distro for people with Visual impairments - just stumbled across it when looking for something else. The user turns on his PC, which boots up the CD, the cock Oralux sings... Then, the user selects his preferences using a vocal menu available in 5 languages. Oralux 0.6 proposes two desktops, Emacspeak and another one based on Yasr (pronounced Yas Er), a few multilanguages voice synthesizers, and is able to select a braille display or drive an external synthesizer. Conference: Is IT Accessible? The University College Northamption are running a conference called, Is IT Accessible?. Since legislation came into effect in September 2002, we should all be creating our work accessibly. This conference will give you information on accessibility and what it means. The conference is on the 9th of September 2004 at University College Northampton Grendon Lecture Theatre.
How to hide a flash movie from screen readers and keyboard users
Adding a Flash movie to your web page may be making the content of that page inaccessible to some visitors. For example, Keyboard users and people using screen reader users are likely to run into the following problems: The keyboard cannot be used to 'focus' on the flash movie, i.e. the user can't tab to the movie object and explore the content. When navigating the flash movie via the keyboard it is impossible to get back out again - making it impossible to explore the rest of the page. Here are a couple of tips for getting around the problems: Make the Flash movie invisible to keyboard users. If the flash movie does not contain valuable content, i.e., it might just be for decoration - the following technique can be used to make the flash movie invisible to keyboards and screen readers: Use the wmode option within the embed and the object tag, <object .....> <param name="wmode" value="opaque"> <embed wmode="opaque ....> </embed> </object> Rather than embedding the flash movie within the HTML page, create a separate HTML page that contains the movie, and link to it. This allows the user to user the back button on their browser to exit from the movie when they are finished. Links I found these tips come on the excellent article about creating accessible flash on the WebAIM website.
What is the object element for? And what's it got to do with accessibility?
Currently we add images to our pages using the img element, we tend to add fancy bits of video or wizzy and exciting flash using the applet element. So why do we need the object element? The object element introduced as part of HTML 4, and is designed to be used for all instances when we want to embed a generic object - such as a flash movie, or a video or an image - into a web page. That's all very well but what's it got to do with accessibility? Well the fantastic thing about the Object elements is that you can use it to provide lots of alternative presentations of your content - you are not confined to providing a simple text equivalent - as you are for when using the img tag. For example, you want to provide a Quicktime video on a web page - but it turns out that some browsers don't have the support for Quicktime - so you can specify that a mpeg movie be played instead, or some other alternative format. If the mpeg movie isn't supported you can specify that a text transcription should be used - and so on. To add the fun - for browsers that don't support the object element you can provide the embed element within the object element as yet another alternative method of delivering your multi-media. So there you go; the object element is a kind of Swiss army knife (so to speak) you can add to your web accessibility tool box. Links W3 Schools Juicy Studio
How to get your XHTML pages to validate when using blockquote.
This is a tip for those on the bleeding edge of web page markup, i.e. those marking up their web pages using XHTML strict. If you are the sort of person using XHTML it is likely that you will want to ensure your pages validate when tested with the World Wide Web Consortiums markup validator. Would it surprise you if I said the following code doesn't validate, <blockquote cite="http//mywebsite.com"> Blah, blah, blah and so on.. </blockquote> It looks simple enough - what could be wrong with that? I came across this very problem - and spent a half hour trying to figure out why it didn't validate. I investigated various options - including thinking that I must have some strange, invisible and illegal characters in my quote somewhere. After scratching my head for a while I looked at the specifications for XHTML and found the answer. To validate as strict XHTML, you must add a block-level element around the text within the <blockquote> tag, like this: <blockquote cite="http//mywebsite.com"> <p>Blah, blah, blah and so on..</p> </blockquote> Problem solved - now my page validates - and so will yours the next time you use the blockquote tag in your XHTML documents.
Is accessible web design a cost or a benefit for clients?
Members of the Guild of Accessible Web Desgners consider whether accessible web design is a cost or a benefit for clients.
Conference: Accessibility in Practice
I am doing a talk at the Accessibility in Practice Conference at the University of Central Lancashire on Wednesday 23rd June 2004. Some blurb from the site, "The Special Educational Needs and Disabilities Act (SENDA) requires that educational providers make sure their websites, multimedia, and e-learning materials are "accessible" to users with visual, aural, physical and / or cognitive disabilities. But what does this mean for developers? Is such an aim realistic, or even possible? This is a one day conference to address the gulf between the theory and the practice."
Web standards and accessibility conference
As reported on GAWDS - Web Essentials '04, Web standards and accessibility conference Here is the press release: University of Technology, Sydney, Australia Thursday September 30 and Friday October 1 2004 Sydney will be the focus of the web development world when it hosts the world's first developer-focussed web standards conference this September. Bringing together some of the biggest international names in web development and accessibility - Joe Clark, Dave Shea and Doug Bowman - Web Essentials 04 aims to break new ground in inspiring web developers, designers and decision-makers to embrace web standards. The two-day conference also features Australian pioneers in web accessibility, design and coding Russ Weakley, John Allsopp, Bruce Macguire (the man who sued SOCOG over website accessibility), Roger Hudson, David Woodbridge and more. Over 300 delegates are expected from Australia and around the world. "Today many websites are failing to meet basic World Wide Web Consortium (W3C) standards" said conference co-convenor and web standards champion John Allsopp. "In the absence of standards, websites are more expensive to run, less effective for users and are vulnerable to legal action." Russ Weakley adds "despite the high profile standards based relaunches of major sites such as http://www.smh.com.au many web developers are only now beginning to understand the importance of these issues. To remain relevant and 'in the game', web designers, developers and decision makers must understand the fundamental standards and practices developed by the W3C, which ensure the web remains and becomes increasingly world wide." Web Essentials '04 will be hosted at Sydney's University of Technology from Thursday September 30 to Friday October 1. Registration is on-line or by phone on 1300 666 770. For further information contact John Allsopp john@webessentials.org 61 2 0405 14 95 97 Web Essentials 04 Sept 30 - October 1 2004 Sydney Australia www.we04.com Maxine Sherrin maxine@webessentials.org Web Essentials 04 Sept 30 - October 1 2004 Sydney Australia www.we04.com A new diagram: what is an accessible website? After some feedback from Gez Lemon, here is an updated version of my diagram,
What is an accessible website? - an answer in the form of a diagram.
A diagram which summarizes my article, What is an accessible website? All access to web pages are mediated through some type of technology; if it isn't accessible to the machine you are using, it won't be accessible to you. You have the best chance of your web page working on these intermediate devices if you use standard markup. People with different needs will be able to access the same content - as long as it can be presented in a way that suits them. Use Cascading Style Sheets (CSS) to make the presentation of your web content flexible. For CSS to work consistently standard markup is required. Use the World Wide Web Consortiums Web Content Accessibility Guidelines to make your content more flexible. Some people will require different content and different presentation. Prioritize your audiences - and spend your budget accordingly to create different versions of your content.
Start with the assumption that you cannot predict the access needs of your audience.
This weeks tip: start with the assumption that you cannot predict the access needs of your audience. For example, a person with Dyslexia may need a particular combination of text and background colours to comfortably read text on a web page. You could contact a person with this particular impairment and ask them about their preferred colours; but do all people with Dyslexia have the same access needs? Unfortunately – from a web designers point of view – the answer is no. A better approach is to design pages so that the presentation of content can be changed by the end user; in the case of the above example, ensure that each person can change the colours to suit their own needs (e.g., via browser preferences or a style switcher). This approach can be applied to all presentation aspects, whether it be text size, layout, or the choice to leave graphics on or off.
Guild of Accessible Web Designers Launch
A new organisation called the Guild of Accessible Web Designers (GAWDS) launched today. It is a an organisation designed to promote accessible web design standards and promote designers and developers who put those standards into practice. By seeking to give those organisations and individuals who practice accessible web design a comptetitive edge - accessible web design skills will become more desirable within the 'web design industry' - and therefore be adopted more widely. The Guild also aims to become provide support, education and eventually accreditation to its members - pushing up skill levels; thus making more sites accessible to more people.
When a link falls at the end of a sentence always put the full stop outside the anchor tag
Consider the World Wide Web Consortium Web Content Accessibility Guidelines (WCAG), Checkpoint 10.5: "Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links. " Generally when trying to ensure that my web pages meet this particular requirement I'm thinking about navigation bars; I'm either marking them up as lists, or putting printable characters between adjacent links (if necessary I make them invisible via CSS). Unfortunately that isn't always enough to ensure a clean bill of health with regard to this particular checkpoint. It is easy - particularly on a page that gets updated often - to violate this rule in the bodytext of the page, e.g., when a sentence that ends with a link, is followed by one that begins with a link. The solution is to get into the habit of adding the full stop after the anchor tag; simple but effective. As web accessibility tips go - it's not the most significant one I've ever published. However, having adjacent links without a printable character between them, means your well crafted page won't pass WCAG Priority 1; and someone is bound to get in touch to alert you to that fact. Links WCAG Checkpoint 10.5.
Why the 'statistics defence' doesn't stand up
I was recently involved in a discussion about whether website designers should be expected to accommodate Netscape 4 users. The case against accommodating Netscape 4 users is invariably backed up with statistics about how few people now use this, admittedly flawed, browser. I've heard 'the statistics defence' (as I will call it) so often over the years that this latest evocation prompted me to think about why I don't agree with this approach. My thoughts and arguments against the statistics defence are not yet fully formed. I would welcome any feedback on the subject. It is such a common argument against accessible web design in general, that a page containing counter arguments would be a good resource for web accessibility advocates. Examples of the 'statistics defence': "We design for 17" screens because that's what most people use these days" "We assume 92dpi resolutions because most people use a PC" "We use IE 5 as a baseline because very few people use old browsers now." "We don't provide an alternative to our flash site, because everyone has the flash plugin these days." "We don't need to make our site accessible because it isn't aimed at, and doesn't get used by disabled people." "We design our site to work on 600 * 800 because that's what most people use." My arguments against this approach I'll give my conclusion first: content on web pages needs to be accessible to Netscape 4 users - and all the other user agents accessing web content. The argument that we can ignore a particular set of users - because they only make up a small percentage of our audience (i.e. they use a particular browser or a particular bit of access technology) - isn't one web designers should be buying into. It is irrelevant whether a person is using Netscape 4, a screen reader, or a keyboard driven text only browser - the issues are basically the same; it is about accessibility of web content. The statistics defence assumes users needs and user agents are predictable What assumptions do many web designers make about their intended audience. e.g. what browsers do they assume they are using? what Screen size? screen resolutions, bandwidth, colour pallette? Are those assumptions based on the computer they have on their own desk, i.e., the one they are using to design the website? Probably - but is this a good approach? - probably not. Have any of the following things changed in the past: browsers, hardware devices connected to the web, screen size, screen resolution, Markup versions? Will these things change in the future? Yes - all of them. Designing for a specific configuration of hardware and software isn't a good way of making pages future proof. Even users with the same hardware and software resize their browser windows to suit their own preferences. A vital lesson to learn is - change is the norm: the most predictable thing we can say is that everything changes. The best chance we have of dealing with this unpredictability is: Use standards so that sites have the best chance of working on the widest range of user agents. Create sites that are flexible enough to deliver our content - no matter what the end user is using. That is not to say that the presentation will be the same on every device - it won't be. The presentation is important - but if the content isn't accessible - the presentation doesn't matter - because there is nothing to present. The web isn't paper Cross platform/cross browser compatibility is the strength of the web - that was the problem it was designed to solve. Designing a web page is not like designing an advert or a bus shelter or a magazine page or a document to be printed on a sheet of A4; where the amount of 'real estate', colours, text size and so on is predictable. To take the specific issue of access for disabled people; do we have to accommodate the needs of disabled people? Do we have perfect knowledge about their access needs? The answer to the first question is yes; in the UK, the Disability Discrimination Act tells us that we can discriminate against disabled people. The answer to the second question is no; we don't have perfect knowledge about the access needs of disabled people. 10% - 20% of people in most populations have some kind of impairment: some of those impairments are not obvious: 8% of men have colour blindness (.4% women) - approx 5% pop with visual impairments - approx 5 - 15% Dyslexia. Once people get older (say over 40) their eyesight, hearing and motor skill start to deteriorate In the university where I work we have many disabled students - not all of them are registered as disabled, but approximately 500 are. Impairment Approximate Numbers Dyslexia 230 Blind/partially sighted 24 Deaf/partial hearing 25 Wheelchair.mobility 21 Autistic or Asperger 2 Mental health 10 Unseen disability (Epilepsy, diabetic,etc) 91 Disability not listed 101 Two or more of the above 21 We don't have perfect knowledge about the access needs of each individual listed above - so we need general strategies to deal with this unpredictability. In terms of approach, dealing with the diverse needs of disabled students isn't much different from dealing with the problem of making sites work on different browsers and different hardware platforms. We have to assume that we don't know what the end user will be using - or what their access requirements will be - and think about what this when we make design decisions. If it turns out that our content isn't accessible on a particular browser - we need to find a workaround to solve the issue (while maintaining standards markup and accessible design). There is always an answer - even if sometimes it take a bit of time to find it. We have to make our websites accessible because it is the law. In the UK we have the Disability Discrimination Act and the Special Needs and Disability Rights Act: and in a university that means we can't discriminate against a student on the grounds of their impairement; reasonable adjustment and anticipation of students needs is required. We can't argue that we won't accommodate disabled students because they only make up a small percentage of the student population. Equally we shouldn't argue that we won't accommodate users with particular browsers because they are part of a minority. In relation to the particular case of Netscape 4, it is legitimate to ask users to upgrade so that they get both the content and the good design - but not legitimate to argue that they won't get the content if they don't upgrade.
Did the DRC report help promote accessible web design?
Pat Byrne of ScotConnect has published a response to the Disability Rights Commission Web Accessibility Report. The DRC report emphasizes the need to include disabled people at every level in the development of websites. Though this is a good approach, Pat questions whether it will be possible for all web developers, the logistics of identifying and recruiting disabled people with a range of impairments. the perception that such evaluators are a resource? would they be seen as altruistic volunteers or would they be paid workers or consultants? would their usefulness cease or would it increase when they become 'experts', with perhaps more informed responses? There is a danger that the report will be interpreted as undermining the value of the World Wide Web Consortiums Web Accessibility Guidelines, and the experience and skills of existing web accessibility experts.
DRC report - more feedback
Maurice Franceschi has e-mailed me his response to the recent Disability Rights Report on Web Accessibility. "However, given that the vast majority of sites cannot even achieve the basic issues I cannot see any clear way forward to getting sites to address the more advanced and broader issues above as long as the DRC takes a softly, softly approach - I mean, they do not even list the 1000 websites tested in the report. In the accompanying webcast there was an obvious reluctance to go to court but at the same time the Australian Olympics case is mentioned as an example of what can happen. I think a high-profile case is going to be what it takes, in the end, to force compliance. If Ryanair can be taken to court and lose over the wheelchair charging, I do not see what the problem is. " He makes some useful and valid points: read the full e-mail about the report. I think Maurice is right - a high profile court case is going to make all the difference.
Don't rely on automated tools for checking accessibility - part 2.
Thanks to Maurice Franceschi of Civic Computing for his reply to last weeks tip about the dangers of relying on automated tools to check accessibility: "Just to follow on from the over-reliance on Automated Tools, a point I fully endorse, by making one further observation on the use of automated tools, in this case Bobby. One great problem we are having with Bobby is that I have found that - like any software - it does have small bugs in it. To Watchfire's credit, I was able to get past the no-can-do support chap and get to a more senior manager who did investigate my issues in detail and got the bugs fixed quickly. However, there are two outstanding problems with Bobby that all web developers need to watch for. 1. Bobby sometimes think a telephone or fax number, or house number, is a 'fixed font size' setting and will return an error on your page. Trivial but it goes to show the fallibility of any software product - even one so universal in use. 2. Bobby consistently returns an error in regard to the naming of anchors, labels, id's. That is, if you have an anchor such as 'Content' or 'FAQ 1' a Form Label attribute (name, id) such as 'Search' or 'Name' Bobby will flag this as an error as it has some sort of internal vocabulary of 'unacceptable hypertext' or 'text requiring context'. This is both very subjective and at times completely inappropriate when it starts to pick up HTML elements that cannot be heard or seen by the site visitor anyway. If Bobby issued Warnings rather than Errors that would be fine, but as it is it makes the business of creating AA and AAA compliant sites that bit more cumbersome. In fact, I have now been involved in auditing several websites that are AAA compliant in every respect but which Bobby continue to fail on this bogus AA issue. We've tried to change the code and text but nothing seems to work. I've been on the Watchfire site and I can see much discussion on this issue so it is a real problem out there for many web designers that Watchfire have failed to address. At the end of the day, I do not care too much as I know the websites are accessible and if I can't put on a Bobby logo it is not an issue for me. There are plenty of instances where the opposite is the case anyway." Thanks for getting in touch Maurice, this is very useful information for developers to know - particularly when clients insist on displaying a Bobby logo to 'prove' their site is accessible.
Formal accreditation in UK for accessible Web Designers?
The Disability Rights Commissions report on the accessibility of UK websites calls for the development of an accreditation for Web Designers, "The Government should facilitate the development of best practice guidance for accessible website development and ongoing maintenance and thereafter promote a formal accreditation process" The Guild of Accessible Web Designers would be the natural home for such an accreditation process.
Don't rely on automated tools for checking web accessibility
The Disability Rights Commission (DRC) released a report this week highlighting the poor accessibility of UK public websites. Among other things, the report highlighted issues related to accessibility testing, "It is very significant that the majority of those Checkpoints that this investigation found to be the most important are qualitative, in the sense that they require the exercise of human judgement. Automatic testing tools alone cannot, therefore, verify effective compliance." http://www.drc-gb.org/publicationsandreports/2.pdf Of course this is not a revelation, web accessibility 'experts' have been saying this for some time, echoing the line taken by World Wide Web Consortium (W3C), e.g., in the article, 'Evaluating Web Sites for Accessibility', you will find the following statement, "No single evaluation tool yet provides comprehensive information or captures all problems with regard to the accessibility of a site; therefore evaluation involves a combination of approaches." http://www.w3.org/WAI/eval/ Your site will be accessible to a wider audience if you take a comprehensive approach; testing by people with different abilities and skills, and evaluation by individuals with knowledge related to accessible web design (that might be you) - or a combination of both. Evaluation website accessibility is an art not a science - it can't be reduce to running your site through Bobby and keeping your fingers crossed that everything will be ok.
Disability Rights Commission find most sites unusable by disabled people
Disability Rights Commission (DRC) tested a 1000 websites and found that most were not accessible to disabled people. 19 per cent of home pages passed W3C WCAG level 'A' , 0.2 per cent passed 'AA', (2 sites from 1000) and no sites passed 'AAA'. Those who are blind or have a visual impairment were found to have the most problems accessing the content and services on websites. Website owners were warned by Bert Massie, the chairman of the DRC, to improve accessibility or be prepared to face legal action. Disability organisations fail to meet challenge on accessibility 'Disability 50' show that the majority of disability organisations do not address accessibility needs sufficiently in their web and digital communications.
Adding captions or providing transcripts isn't always enough
If you search the web for information related to web accessibility for deaf people you will find plenty of advice about captioning or providing transcripts for web based audio and video material. What you are unlikely to find much discussion related to accessibility and language; for many deaf people English is not their first language, Sign Language is. Although Sign Language provides an equivalent for everything that can be spoken or written, understanding written English - for some deaf people - is a process of interpreting from English to their first language, i.e. Sign Language. Writing simple language and short sentences can help to make information more accessible to Sign Language users. However having discussed the issues with various informed users in the past (e.g. those at the Sign Language Interpreter Service in Glasgow) it seems that the most effective way to make content accessible to Sign Language users is to provide a Sign Language version of all content. The problem here is that the obvious way to do this, i.e., providing video of Sign Language interpreters, is an expensive and resource hungry exercise . For this reason, many people are experimenting with signing avatars (virtual humans) as a way to deliver Sign Language equivalent to written content. Links Sign Language Interpreter Service Signing Avatar from 3D.com signingbooks.org BBC article on signing avatars: Visit the tips archive Send me an e-mail (jim@mcu.org.uk), or give me a call (0781 0098 119) if you would like assistance to make your website accessible - the MCU has being learning how to make websites accessible since 1996 - so we know a thing or two about it. Have a good Easter weekend (or the equivalent - if Easter is not your thing).
An example: UK University Accessible Web Design Plan
This Accessible Web Design Plan may provide a useful 'jumping off' point for universities in the UK as they consider developing their own web accessibility policies and plans.
Accessible PDFs with Adobe Acrobat 6
Interested in creating accessible PDFs? You will find some good ideas in a guide I have written for ScotConnect: an easy to read practical 'how to', for creating accessible Adobe Acrobat 6 PDF documents. Developing guidelines to determine which documents should be published as PDFs. Preparing source documents for the conversion process. Testing the accessibility of PDF documents after they have been converted. Find out how to make the best of the built-in features and test tools. Creating accessible PDF forms. A summary of techniques and tools for creating accessible forms within PDF documents. Anticipating client side accessibility issues, and educating users about new accessibility features:
The Advantages of Using Valid HTML
I have updated my page on why it is a good idea to use standard markup when creating web pages. In Glasgow Caledonian University we have recently been deciding what DOCTYPE to use for university websites. Currently I would advocate the use of XHTML 1 Transitional - for the following reasons: Because it will encourage stricter adherence to standards based markup. Because using 'transitional' gives us more leeway when it comes to ensuring that pages will still display even when there are markup errors - as there inevitably will be given that people will be using tools to update pages, that don't always help create clean code. XHTML Transitional pages should display as consistently as HTML 4.01 Transitional assuming we markup pages according to the rules. We will have the option of - in the future - making simple changes to the meta information of web pages to ensure make the pages compliant with future browsers that understand XML. Political reasons. For information that is unlikely to be 're-purposed' (i.e. for PDA, or mobile phone use) HTML 4.01 is probably a better technical solution - as it is the only standard that works without 'workarounds and head-in-the-sand-ignore-the-fact-that-we-are-not-really-standard-compliant' botchups. See the article at http://hixie.ch/advocacy/xhtml for an explanation of why it is not possible to use XHTML correctly in current browsers. It is important that we look as if we are forward thinking; for the most part the workarounds associated with using XHTML 1 Transitional do not have sufficiently negative effects on display or document structure to worry us unduly at the moment. I would not underestimate the impact of appearing to be forward thinking (I have underestimated this in the past myself), or the political advantages to be reaped from adopting a approach that is fashionable. By using XHTML 1 Transitional, we don't have to spend loads of time explaining why we are using the 'older' HTML 4.01 standard - particularly as the reasons are hard to explain, and hard to understand. Some things to read and look at: An introduction to standard HTML and accessibility HTML 4.01 or XHTML for university web pages? (I am now arguing for XHTML transitional - I've changed my mind) Conforming DOCTYPE templates: Choosing a DOCTYPE Fix Your Site With the Right DOCTYPE! Potential problems of switching to XHTML
Is your website legal?
A new article by Trenton Moss: Web accessibility and the law in the UK: Is your website legal? "There's been widespread speculation about the new legislation being introduced, which will ensure that websites are accessible to disabled users. Try to find specific information about it on the Internet and chances are you'll come up empty handed." layout your forms using CSS instead of tables. I am a fan of using CSS for layout and presentation of web pages - but I do still have a few 'blind spots' when it comes to putting my good intentions into practice. For example, I still tend to use tables when creating layout for forms. I was recently alerted to this weeks tip by Tavis Reddick, the webmaster at Fife College; while communicating about another forms related issue, he pointed me to a useful article about using CSS to layout forms (scroll down the page to find the part about forms layout). I won't reproduce the example code here - because it is not the simplest technique I have come across - and I couldn't figure out a way to simplify it for 'tip size' consumption. However, I thought it was worth highlighting this example, as it demonstrates that CSS is flexible enough to be used for tasks beyond the simple two or three column page layout. References. Fife College Practical CSS Layout Tips, Tricks, & Techniques
Accessible Web Typography - Russian translation
I notice that EServer TC Library - a cooperative library for tech communicatores - gave, 'Accessible Web Typography - an introduction for web developers', five stars, and the top rating of 'best'". Yura Zemskov has translated the section on usability in to Russian.
Associate form fields explicitly with their labels
Here is handy accessibility tip that will make filling in web forms easier for screen reader users, and for people with impaired motor skills: associate form fields explicitly with their labels by making use of the 'label' element and the 'id' attribute. When encountering a form on a web page it is easy for sighted users to work out the expected response for each form element; it is just a matter of reading the label next to the field. However, it is not always quite so simple for someone using a screen reader. It may not be clear which labels are associated with which field (particularly if the page author has used tables to layout the form, and the screen reader doesn't understand tables). If labels are not physically, close or clearly associated with the form element, filling in a form can be extremely difficult for screen reader users. There is a way to explicitly relate labels with their form elements; each label can be identified with a name, and then associated with the appropriate control using the 'id' attribute, e.g., <label for="name">Name</label> <input name=" Name" type="text" id ="name" /> The value of the for attribute can be any text you choose - as long the appropriate id attribute has the same text. Using this technique also provides a bonus for people with impaired motor skills because it increases the 'target area' when assigning focus to the field, i.e. clicking the label or the field itself will focus the cursor in the text field (or check the box if it is a radio button).
Ready made style sheets to meet your access needs.
Here is this weeks web accessibility tip: download ready made style sheets to meet your access needs. I came across this tip while reading through the latest copy of The E-Access Bulletin: technology news for people with vision impairment. It is a little known fact that users of the Internet Explorer 0n Windows can apply their own style sheets to web pages by setting the appropriate accessibility option in their browser. However, the flaw in this scheme is that most users don't know how to create their own style sheets, and if they did it would take a while to develop one that meets their needs exactly. Daljit Singh has addressed this problem by providing a service where users can choose their preferred font sizes and colours, and have a style sheet created for them - based on those preferences. The resulting style sheet can then be downloaded, installed, and set to be automatically applied to any standards based web pages using style sheets for presentation. While I am talking about style sheets, I'll take this opportunity of reminding you of my own PHP based turbo charged style switcher. Follow up on last weeks tip. Last weeks tips was about using Javascript to get around the problems caused by adding characters in form fields to pass WAI accessibility guidelines. Here is some of the feedback related to the tip: The general consensus was that the Guideline itself is obsolete, and creates more of a usability issue than solves. Patrick H. Lauke has spoken to Shawn Lawton Henry, and it looks like we will see this checkpoint disappear in the next version of the guidelines. Patrick also pointed to a similar technique he has used. Tomas Caspers also uses a technique to deal with the problem. Gez Lemon wrote to suggest a modification of the javascript: Rather than specifying a string literal for the check, you could reuse the same event handler with: onfocus="if(this.value==this.defaultValue)this.value=''" Thanks, I appreciate the feedback.
Juicy CSS Accessibility Analyser
Gez Lemon has come up with yet another useful addition to the accessible web designers toolbox - a CSS accessibility checker. I could take the time to tell you what it does, or be lazy and leave that job to Gez: "I've been working on a CSS accessibility program. It's a very basic service at the moment, but I'm hoping over time to make the service highlight potential accessibility issues. At the moment, it validates the CSS using the W3C's validation service, checks for colour contrast between foreground and background colours, and then checks that relative units have been specified for font sizes. It also has an option to check that relative units have been used for margin, padding, and width. At this point, I wouldn't say it's amazingly useful, but it's an extra tool that might be useful for developers wanting to ensure their work is accessible." More information can be found at Juicy Studio. The service is available from http://www.juicystudio.com/services/csstest.asp. Results from a CSS test falls into one of three areas: I tested the MCU stylesheet, and got a few warnings because I had either not specified both foreground and background colours, or used transparent as the background colour. I also got one error, because I made the background and foreground colours for my banner the same - which is exactly as I intended - so it proveds the CSS checker is working as advertised. Well done Gez - looks like you are onto something here!
Use Javascript to add default text to input fields.
For as long as I can remember I've puzzled over whether or not to put in default characters in edit boxes and text areas in my web forms. On the one hand if I don't my page will not will not pass Guideline 10.4, and will have no chance of WAI AAA compliance. Guideline 10.4 exists to ensure visitors using some older screen readers (which don't recognize empty form fields) - can fill in web forms. Unfortunately, if I add default text in my form fields I create problems for another set of users, i.e. those who have to delete my text before entering their own. I also create additional work for my forms processing script; which has to check for, and remove any remaining default characters (many people don't bother deleting the default characters when adding their own text). I have gone through periods of not adding default text - and having to explain why my forms don pass AAA web accessibility tests - and adding text, and dealing with the associated problems. I had resigned myself to the thought that this was one of those web accessibility problems that has no simple solution. However, it looks like I may have been too quick to give up on it. While surfing on the Juicy Studio website I notice that Gez Lemon (the owner of the site) was using Javascript to add default text to his forms - and that the text disappeared when I clicked in the form field. The form passed the 10.4 Guideline, and caused no problems either for users or my form processing script. The surprising thing was that it was very easy to add this facility to my own forms: Here is an example from a field in my comments form (only the relevant attributes are shown). <input type = "text" name = "membername" value = "Name" onfocus="if(this.value=='Name')this.value=''" /> The value of the filed is set to 'Name'. The inline Javascript code 'says' if there is focus on the form field (i.e. I have clicked so my cursor is in the field), check the default value and if it is 'Name' make it an empty string. The relevant short script is as follows: onfocus="if(this.value=='Name')this.value=''" Fantastic - one more accessibility compliance problem solved. Get back to me if you are aware of any issues with this technique that I have failed to appreciate. Links and references Web Content Accessibility Guidelines 1.0 Juicy Studio From the WAI Guidelines: 10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. [Priority 3] For example, in HTML, do this for TEXTAREA and INPUT.
Accessible Web Typography, an introduction for web designers - now online
The full text of my short(ish) book, Accessible Web Typography, an introduction for web designers is now online. Please add your comments, disagreements and tips to the bottom of the relevant pages.
Weekly tip: Adding Tags to PDF documents improves accessibility
Here is my first weekly accessibility tip for 2004: Adding Tags to PDF documents helps to make them more accessible. A screen reader is not a particularly useful tool if it cannot not read out the text of a document in the correct order, or if it cannot distinguish between structural elements such as headings, links or paragraph text. With this in mind Adobe has, adopted a strategy of 'marking up' the structure of PDF documents using tags; much in the same way tags are used to markup HTML pages. Marking up the PDF document enables compatible screen readers to read the text in the appropriate order (i.e. the order of the tags is the reading order of the document), and to make use of the information provided about document structure in a way that helps increase accessibility for users. For example, in a tagged PDF document, when the text is presented in columns the screen reader understands that it should read down the first column, before moving across to read down the next column. In an untagged PDF document, would be read from left to right across the page - which makes no sense at all when dealing with columns of text. So how do you add tags to your PDF documents? There are a few ways you can add tags to a PDF document, but probably the best way is to ensure that they are created automatically when converting your source document. In Word 2000 and above, do the following: If you are using Acrobat 6 Locate the 'Adobe PDF' menu and choose 'Change Conversion Settings'. In the application Settings tab, select the option to 'Enable accessibility and reflow with Tagged PDF' - and click OK. If you are using Acrobat 5 Locate the 'Acrobat' menu and choose 'Change Conversion Settings'. In the 'Office' tab select the option 'Embed Tags in PDF (Accessibility, Reflow)', and click OK. When you click the convert to PDF button, the resulting document will be a tagged document. (The above instructions assume you have installed Office 2000 or above first, and then have you installed Acrobat 5 or 6.) There is a lot more to creating accessible PDF documents than just ensuring that you add tags to them - a good place to start your learning is the Adobe accessibility website. You can find more tips in the tips archive. My last tip highlighted a useful accessibility toolbar, which unfortunately did not work on Macs. Both Adam Larsson and Pierre Lemieux got in touch to tell me about the PNH Toobar for Mozilla that is Mac compatible.
The web accessibility toolbar
In this weeks tip, I recommend you check out a new Toolbar for Internet Explorer, developed by Steven Faulkner, of the National Information and Library Service (NILS). Support for the toolbar is confined to Internet Explorer on Windows, so I haven't been able to try it out myself (I use a Mac) - however, Gez Lemon of the website Juicy Studio is giving it glowing reviews - and I trust his judgement. According to the blurb, 'It is designed to help the user to interrogate aspects (structure/code/content) of a html document that can have an affect on the accessibility of that html document. ' It does all sorts of things I would find useful as a developer of accessible websites (validation, screen resolution changes, CSS on/off , links to online checking tools and so on), so I think you will find it very useful. You can find installation instructions, and a full feature list for the accessibility toolbar on the website. This is my last accessible Web Design tip for 2003, I'll be taking a break from the weekly tip until mid-January. I hope you have found the tips useful; if you have any suggestions about how I could improve them don't hesitate to get in touch (pitched at the right level? too short, too long?) Have a good Christmas and happy and successful 2004. :-) All the best, Jim p.s. In last weeks tip I provided a link to the old free version of Bobby - I'm sorry to say, the link is no longer alive. I must have woke somebody up to the fact that it was still available, because it promptly disappeared after my post.
3 tips: free Bobby, free Waizilla, and use Acrobot
I am sorry that I was unable to provide my usual accessible web design tips over the last couple of weeks; I got caught up in a number of projects that kept me very busy. To try to make up for my tardiness, this week I am offering 'three tips for the price of one'. Tip 1. Although Bobby, the web accessibility evaluator, is now a commercial product (and the website version only lets you evaluate a page once a minute), did you know that you can still download a free version of the Bobby evaluator? I recently found a link to the original download on the WATS.ca website, along with a host of other useful accessibility testing tools. Download the free Bobby accessibility tester (requires the Java Runtime Engine which is included in the download). Tip 2. While I am on the subject of web accessibility checkers, you may, or may not, be aware that a free cross-platform website accessibility testing tool called WaiZilla, is currently being developed by Tim Roberts, and a group of other programmers . This is an Open Source project, so not only can you can keep up with developments by regularly visiting the website, if you are interested and have the appropriate talents, you can also contribute to the development process. Tip 3. If you find that marking up all your acronyms has become a bit of a chore, you may be interested in a tool developed by Ian Lloyd on the Accessify website; the Acrobot - Abbreviation and Acronym Generator. This useful tool will find acronyms in your HTML, add the <acronym> tag, and the appropriate title attribute. There is also a 'favelet' provided on the site to make it even easier to pass text through to Acrobot. The tips archive is at: http://www.mcu.org.uk/weeklytips/
Guild of Accessible Web Designers opens for business
The Guild of Accessible Web Designers (GAWDS.org) - a membership organisation set up to promote the practice of acccessible web design, and the interests of accessible web designers - went public for the first time today. The official launch of the Guild will not be until early in 2004, but todays 'soft launch' is intended to attract new members who have the time, enthusiasm and skills and motivation to contribute to the development and growth of the organisation in its early stages. Already the list of members and supporters includes well known 'names' from the world of accessible web design - adding credibility to the venture. More news is promised soon from the founders of the Guild. Do yourself a favour, support the cause, and become a member now.
Make HTML pages created from MS Word more accessible
Many HTML pages are still being created using Words in-built 'Export to HTML' function, so in this weeks tip I explore some simple ways to make the resulting web pages a little more accessible (than they would otherwise be). Using Word to create HTML pages is not ideal, as the program has a tendency to add a lot of extra 'junk' to the resulting markup; the extra markup is used to try to make the Web page look similar to the original Word document. However here are two important techniques that will help you to ensure your resulting web pages will be a bit more accessible, particularly for people who are using screen readers: Use the styles facility within Word to add structure to your documents, e.g. instead of just making your headings bold, use styles to assign the appropriate level of heading. The structure will be retained when the document is converted to HTML. 'Screen readers' will use the document structure to help make reading the web page more efficient, e.g. by presenting all of the headings on a page in a summary list, so that the user can jump straight to the part they are interested in. Add alternative text to all your images (right click, and select format picture); these labels will be retained after the document is converted to HTML and can be read out to the user by screen reading software. Visit the tips archive.
Scottish Arts Marketers' Forum: accessible web design
Last Thursday I lead a 'round table discussion session' on accessible web design for the Scottish Arts Council Marketers' Forum. It was an enjoyable experience - here are some of the issues that came up and brief versions of my answers. How do blind people surf the web? What should we be aware off when designing for someone who is blind? Many blind people, and people with low vision use a 'screen reader' which 'reads out' (i.e. turns into audio) the text on a web page. This has implications for making a site accessible to someone who is blind: Pictures can't be 'read' - so labels have to be added to the pictures to indicate their purpose or the content they contain. There also needs to be alternative ways to access the information contained in all non-text elements such as videos, or animations, e.g. a transcript or captions could be provided along with a video. Having information read out - is a 'linear' experience - generally screen readers will start to read from the top left of the page and work their way down. Depending on how the site is designed it can either be a long and tedious experience, or one that is a pleasure to a blind person because it either ignores or takes into account how screen readers work. For example, if the first section on each web page is the navigation bar, and the navigation contains 100 links, then the screen reader has to read out those 100 links before getting to the content of the page. There are many ways of getting around this problem; one would be to put the content first on the page and the navigation second, another would be to provide a way of 'jumping over' the navigation bar straight to the content. The arts community needs aesthetically pleasing websites - do accessible websites need to be just text and therefore look boring? The idea that accessible websites need to be text-only is a myth; most of the changes required to make a website accessible do not affect the visual appearance of the site. Whether the site is aesthetically pleasing or not, is not related to how accessible it is - it is related to the talents of the web designer, and how well the designer and the client have thought about the goals of the site. An awareness of accessibility issues can however lead to changes that improve the usability of the site for everyone. For many people a site which contains pictures, animations, sound and video will be more accessible than one that contains only text. Using different communication mediums means offering more choice to the visitor to the site - and that can only be a good thing. Well designer, good looking websites, that make good use of multimedia technologies offer a richer experience to the visitor - however as mentioned earlier provide alternative ways of accessing information within non-text content. Mostly arts related organisations do not have a lot of money - is it more expensive to build an accessible web design? I am not aware of any research that shows whether or not it is more expensive to build an accessible website. Testimony be web design experts during the legal proceedings in Australia (when an individual took the Olympic Organising Committe to court because their site was not accessible), estimated that the cost of building an accessible website adds 2% to the budget of the site. In the medium to longer term the support costs for an accessible website are lower. For one thing, there will be less e-mails and support calls from people who can't access the information on your site. Creating an accessible website helps the designer to think about important aspects of the site such as how the content of pages are structured, and how logically the navigation of the site is organised; getting these aspects right early in the design process will make the site easier and cheaper (certainly in terms of time) to manage in the long term. Some aspects of making a site accessible will be expensive if they requires specialist knowledge, such as adding captions to video, or creating content in several languages. Making a site accessible 'retrospectively' tends to be more expensive than creating an accessible website from scratch. We don't want to discriminate against people with colour blindness, are there any colours should be avoided? First, ensure that you don't design your site in a way that means visitors cannot change the colours to suite their own needs. Second be aware that 15% of men have some form of colour blindness (only .4% of women); the most common combinations of colours that can cause problems are red/green (remember red berries on a tree with green leaves) and yellow/blue (remember the swedish flag or yellow daffodils against a blue sky). Using these colours on their own is generally not a problem, it is only when they are used as in conjunction with one another that problems of contrast occur, e.g. red text on a green backgound; both may look like grey to someone who has colour blindness.
User customization using a style sheet switcher and scripts.
Gez at Juicy Studio has created an ASP version of my turbo-charged style sheet switch