By guest interviewer, Maxine Sherrin
Russ Weakley is a web designer for the Australian Museum who somehow in the last few years has also found the time to:
Russ: When I began working on the web in 1995, I didn't understand that web design was totally different from print design.
While print design is about controlling every aspect of design (layout, colour, font face and size, paper stock etc), web design is about focussing on aspects that can and should be controlled, and then letting users control all other aspects.
So, I had to unlearn the "total control" mentality and accept that users may view my sites in a variety of browsers and devices, with different monitor sizes, font sizes, colour settings, platforms and operating systems. I also had to accept that users had the right to control aspects of the layout - particularly font sizing.
The most important thing I learned was "scalability". This has nothing to do with CSS or standards, it is understanding that content has to be able to grow. It can sometimes grow sideways, but if fixed widths are used, will always grow down. The simplest test for page layouts is to radically increasing font size. Layouts that are flexible and hold together at a much larger font size are an indication that the designer/developer understands the medium.
For me, the move to standards happened in a series of phases. I started learning about valid markup, then CSS, semantically correct markup and finally, accessible markup.
Looking back, I learned standards the wrong way around. I focussed on presentation before really understanding the basics of document structure.
Ideally, it would be better to start with fundementals like:
Once these were understood, CSS is much easier to understand and apply. So, the next step would be:
The main reason I started writing tutorials like Selectutorial was to help developers who are getting into CSS learn the basic concepts as early as possible - and hopefully to help them avoid the mistakes I had made.
Russ: Years ago, I was involved in a group called DCI - Designers for Cultural Institutions. The aim of the group was to bring exhibition and graphic designers together so that they could talk about issues related to their profession. It established a great network between designers from Sydney-based cultural institutions.
When I moved into web design, I missed having access to other designers in the same field. There was no one to share ideas with, or to ask for advice. At the time, there didn't seem to be any web design groups around, partially because the profession was so new.
In January 2003, Peter Firminger and I tried to set up a web version of DCI - for Government web designers and developers. Unfortunately, there wasn't much interest at the time.
Soon after, we came across an online tool called "Web Standards Meetup". We started hassling anyone we knew to come and join and within a few days we had some interested people (mostly from a local mail list called CFAussie).
Our first meeting was held on 6 March 2003 in a pub in Sydney. The 8 people who attended immediately decided to start our own group, set up a mail list and hold meetings where we could share information. Peter and I offered to set up a website, a mail list and organise regular meetings. The "Sydney Web Standards Group" was born.
Although Peter and I are the public face of the Web Standards Group, without the enthusiasm and commitment of those original 8 people, the group would never have happened. Most of them are still active members.
We soon had people from other countries joining the group, so we dropped the "Sydney" and became the "Web Standards Group (WSG)".
This name change caused some early confusion, as people thought we were related to the Web Standards Project (WaSP).
However, the two groups have very different aims. WaSP has focussed on browser makers and tool developers - lobbying at higher levels. The WSG has always focussed on the exchange of information between designers and developers through the mail list and meetings.
We currently have over 1900 members from a wide range of countries. While Peter and I still do a lot of work, we now have a very supportive and hard working core group who run meetings in various cities, help with the mail list and provide input into future directions.
Of course, the most important aspect of the WSG is the members themselves. The mail list is filled with members who freely give their time and knowledge to other developers who are in need of advice, or standards related help.
One of these days we'll get time to revamp the tired old WSG site.
Russ: During my first few years of web development, I was completely unaware of web accessibility. In fact, I perfectly fitted the category "Ignorance is bliss".
This attitude gradually changed when I started developing with web standards. However, the importance of accessibility didn't really sink in until I started watching people with disabilities interact with my sites. I have Roger Hudson to thank for this.
Roger is a Sydney based usability and accessibility expert who has been conducting usability and accessibility testing for some time. I have been able to sit in on a number of his sessions and observe a variety of users.
It is a sobering experience to watch a blind user struggle with poorly structured forms, to watch a vision impaired user deal with poor colour contrasts, or to watch a mobility impaired user negotiate a site without a mouse. It is even worse when the sites being tested are your own!
To anyone who is interested in getting into accessibility, I would thoroughly recommend watching real users interact with your websites. When you see people struggle with basic website functions, it becomes very clear that accessibility is not about meeting legal obligations or producing compliant sites, it is about empathy - making sure your sites are accessible so that people are not disadvantaged.
Russ: Accessible markup benefits a wide range of users, including blind users. However, if you build accessible sites as part of your normal practice, this question is almost irrelevant. You shouldn't have to devote large amounts of time to deal specifically with blind users.
I have a problem with this question for a number of reasons.
1. The question assumes a simplistic view of blindness - if blind people cannot see paintings, photos or sculptures, they will not need to come to the website.
What about a blind user who wants to find out some information on a local artist, and goes to the local art gallery website to read the artist biography?
Many art galleries are also used for parties and functions. What if a blind user wants to look up an art gallery website to find opening times, location and function details?
In both cases, an inaccessible site will lead to a frustrating experience.
2. The question takes a very narrow view of art - that it is purely visual - which is not the case. Art galleries could host experimental sound exhibitions, tactile experiences or sculptures exhibits that are deliberately designed to be explored through other senses.
For example the Royal Blind Society runs an annual art exhibition titled 'Tactile Art' with the Object Gallery that encourages visitors to get 'hands on' and experience contemporary works of art through their sense of touch.
3. Making sites accessible can often benefit a wide range of users.
If an art gallery site has artworks that are labelled with clear, informative descriptions, then many users could benefit. If nothing else, these descriptions could be indexed by Google, and could help other people who are searching for artworks online.
If longdesc (or more widely supported equivalents) were used, artworks could be enriched with detailed descriptions of the artworks as well as history of the artworks, the techniques used, the artists frame of mind at the time of production etc. Again, this could be beneficial to a wide range of users.
If artworks had clear descriptions, another group of users who would benefit are those on slow connections who browse with turn off images. Clear descriptions would allow them to travel quickly through the site until they came to the artworks they wanted to view.
So, to answer your question: yes, I believe you should make an art gallery website accessible to blind users. Why? Because blind users may want to visit the site, and even if they don't, the accessibility features may aid other users.
Russ: First of all, Flash can never be accessible to everyone. For older screen readers, it is completely inaccessible.
Secondly, if Flash is to be used, it should be made as accessible as possible, and alternatives should also be made available for users who cannot or choose not to use Flash.
Although Flash is not a recognised W3C standard, there are times when it could be used to enrich or illuminate in ways that cannot be achieved with HTML. An example would be content created for users with cognitive impairment and learning difficulties. Some concepts are easier to understand when presented as simple animations rather than explained in words.
The opposite is also true. Flash should never be used for complex data tables, as it does not support data table accessibility features.
What are the best methods of achieving Flash accessibility? Bob Regan recently posted a detailed article on this, titled "
WCAG 1.0 Guidelines and Checkpoints for Flash" (no longer online).
Personally, I do not use Flash at all any more. The last time I used it I got into a lot of trouble!
Russ: It is easy to see why dropdown menus are appealing to some developers. You have all the navigation tucked away in one spot and users can jump to almost anywhere in the site in one step.
My main problem with these menus as that they are often hard or impossible to use for certain user groups.
When people say that some dropdown menus are "accessible" they generally mean for blind users. However, there are other audiences that can find these menus hard to deal with.
1. People with arthritis, Parkinsons and other forms of limited mobility often find it very hard to use dropdown menus. It takes a degree of dexterity to move the mouse to the desired dropdown item.
Though they are less than ideal in many ways, methods that allow some sort of delay before the menu disappears can be beneficial to these users.
Also, dropdown lists that are directly below the main list item are much easier to use than side dropdowns (or flyouts) where the mouse must travel sidewards along the list item, and then down the dropdown list.
2. People who use screen magnifiers often find these menus hard to use. When the screen is magnified extensively, dropdown items can sometimes disappear off screen. In some cases, it is impossible to navigate to the dropdown items, as moving the visible screen area deactivates the dropdown.
3. Many dropdown menus are built using nested lists as the underlying markup. This is commonly considered to be the most semantically correct option - it is something I have used extensively, and promoted.
However, I recently found out that blind users using certain versions of JAWS can have trouble with nested lists - the user is not notified when they leave the nested list and move back into the main list again. This can cause considerable confusion - especially when the nested lists are part of a complex site navigation.
This could be solved a number of ways, including the use of
<hn> elements with lists rather than lists and nested lists.
4. Although this many not be a major concern for every site, people with cognitive impairment (even mild cognitive impairment) often find these menus hard to use and understand.
The solution in a lot of these cases is to provide a back-up option. One example would be providing an index page in each section of the site that listed all pages within the sections .This would allow users to navigate through the site without the dropdown menu. Another option is a full sitemap. However, it is not ideal for users to have to navigate around a site using a sitemap.
The bottom line is that you can build a dropdown menu that is css based and semantically correct. You can even build dropdown menus that meet most or all of the WAI guidelines. However, there will always be users who find these menus hard, and in some cases impossible to use.
Russ: My feeling is that when designing a site, you should put aside any detailed thoughts of how you will build the finished product and focus on what you want to achieve - the overall feel, the user experience, the balance of layout etc. Only when you are completely happy with the design would you put your coding hat on and decide how to build it.
Of course, it is good to be able to keep certain considerations in mind when designing, so you don't design something that will be completely impossible or impractical to build in CSS. The point here is not to let your knowledge of what is possible in CSS dictate your design. It is very easy trap to fall into (I have fallen in on many occasions) and it can lead to designs that are possibly less creative.
One way to turn off the CSS part of your brain during the design phase would be to use a more formal process. After receiving the design brief you could:
I have never used all of these processes in one job, but have found each of them useful at various times. They help to disengage the CSS side of your brain so that the design process is freed up.
Russ: Many developers are choosing to use XHTML instead of HTML as they move towards web standards. Some of these developers use XHTML without looking at all the issues.
My advice to anyone thinking about using XHTML would be to read all the information you can on the advantages and disadvantages of XHTML so that you can make an informed decision.
If you feel that XHTML is the most appropriate choice, you will then be faced with the "MIME type challenge" which is:
To solve this MIME type challenge, you then have to choose one of the following options:
There are many detailed articles that explain the issues associated with these three choices:
At the risk of being burned at the stake, I think that unless you are willing to serve your pages as application/xhtml+xml with content negotiation, then you are probably better off staying with HTML 4.01 at this time.
I prefer HTML 4.01 Strict over HTML 4.01 Transitional, as it forces developers to separate content and presentation more fully than Transitional. For example, presentational attributes such as align, background, bgcolor, border (for images and objects), clear, color, face, hspace and many others are allowed in Transitional, but not in Strict. Using Strict also forces developers to structure and mark up content more thoughtfully as you cannot have inline content directly inside the body, blockquote or form elements.
The bottom line is that each developer has to make their own choices.
Russ: Yeah, I've heard about them, but I'm definitely not cool, so that rules me out.
My time is currently divided between:
If I started blogging, my fear is that these other activities would suffer - especially the family.
I think it is also important to look at where your input is most beneficial. My main strength is being able to break down concepts and explain them in simple ways. So, when I have the time, I prefer to write more detailed articles on specific topics rather producing shorter, more regular blog posts.
Who knows, that may all change soon. I may become cool, and then I will NEED a blog!
Copyright © Web Standards Group 2012