Technology has advanced to a point where almost anyone can set up a website – no coding experience needed! It’s easy to get carried away with glitz, glamour, flashing signs and a swinging carousel of images. This is where user experience, or UX, comes into play. And let’s not forget web accessibility. Many of us have something to do with a website. So whether we contribute to one, manage one, or are commissioning one, there are some basics to know.
First some statistics. Seventeen per cent of users will not return after just one bad experience. Forty-eight per cent of users are annoyed by sites that aren’t mobile friendly.
The DreamHost blog has two articles, one explaining how UX works, and the other is about web accessibility. It’s a pity they weren’t joined up into one article. Accessibility is not an optional add-on. It should be considered from the outset of the initial design and be a continuous process for ongoing content.
While the UX articlefocuses on “target audience” and forgets this audience might need accessibility features, it has some useful advice. No need to get too bogged down with detail here. It covers navigation, content, animation, and responsiveness.
The article, 10 ways to make your website accessible is a good start for anyone new to the concept. It covers many of the basics such as colour choice, adding descriptions to images, and text size. Avoid tables for presenting data because screen readers can’t read them unless they are coded correctly. An accessible site expands the potential audience and helps with search engine rankings.
Editor’s note: We do our best with accessibility and rely on in-built coding with the free software we use to keep the site running. We receive no funding to run this service. However, we welcome feedback if you find specific difficulties with this website.
Make your product more usable by more people in less time. That’s a great aim, and it is the opening line in the IBM Equal Access Toolkit. With many websites remaining inaccessible, this toolkit assists web developers and designers increase accessibility. It comes with Accessibility Checkers and has reporting tools for accessibility conformance.
Non-tech people should also have a look at this Toolkit especially if they are in charge of contracting a web developer for their website. Or when they update their website.
There are five steps: Plan, Design, Develop, Verify, and Launch. The process inolves the whole team regardless of their level of expertise.
The Equal Access Checklist is where it gets technical and links to the WCAG2.0/2.1 Checkpoints. There are four principles underpinning the process.
1: Perceivable – Information and user interface components must be presentable to users in ways they can perceive.
2: Operable – User interface components and navigation must be operable.
3: Understandable – Information and the operation of user interface must be understandable.
4: Robust – Content must be robust enough so it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
For an overview, G3ict has a media release explaining why this toolkit is needed. Accessibility is an issue that comes up in legal and policy discussions in many organisations. While many websites have improved their accessibility there is still a long way to go. It is worth noting that a new site might be fully accessible but as new material is uploaded, it isn’t always checked for accessibility over time.
When organisations decide to refresh their website they usually focus on factors such as positive brand imaging and deciding what information is the most important. So the idea of involving users at any point can be a bit scary. What if they want to change things? What if all our brand work is undone? Can we really afford the time to do it?
The bottom line is that if you don’t involve users from the outset then your website will receive less traffic. Being willing to accept feedback, particularly on accessibility, gives all website visitors a good experience. And don’t assume your web designer has all this in hand. Very few home pages are accessible in spite of legislation requiring this.
The W3C Web Accessibility Initiative has a toolkit to guide web designers AND organisations through the process of involving users. The toolkit includes a one minute videoof why designers should include users from the outset. The material is focused on users rather than technical aspects. It helps avoid some of the pitfalls and at the same time improve general usability for everyone.
The toolkit is extensive and each section is downloadable separately. The title is, Involving users in Evaluation Web Accessibility.
Digital infrastructure accessibility and content accessibility are not the same things. Infrastructure covers things like elements that show up on every page and anything related to navigation. Content is anything that can be updated and uploaded. So that’s text, documents, articles, photos and videos. A key point in an informative article from Sheri Byrne-Haber is:
Every single time the content is updated, content accessibility should be reassessed.
This is particularly relevant if staff or third parties are free to upload content onto a site, or are providing content. The other key point is:
Accessibility is never one-off and done.
The article uses a case study to show how organisations can be left vulnerable to lawsuits if they don’t check regularly for accessibility. Webpages can be accessible today, but next week they might not be because new content has not been assessed for accessibility. The title of the article is, What’s more expensive than getting sued over inaccessibility?.
The answer to “Is your site accessible?” is sometimes, “I haven’t been asked that before” or “I’m not sure I understand what you mean”. Some website managers will quote that they are WCAG2 compliant, but that doesn’t mean they know what it’s about. Some parts of the website design might be compliant, but some of the content might not be. So things like e-books, e-learning or customised apps could pose problems when it comes to accessibility for all. An article by Andreea Demirgian takes a look at these issues and more by using real examples of online chat conversations with web operators.
A related article, Do you see what I see… Accessibility challenge – CSS! gives instructions on how to find out if the CSS of the website is a barrier to accessibilty. A bit technical but gives insights into what web design should consider. The article is by Herin Hentry of the Reserve Bank of Australia.
Screen magnifiers are used by people who have low vision. It enlarges the text and images to a size where only part of the page or picture is visible at any one time. It is not the same as using the zoom function in the browser where the layout is changed to match the width of the screen. This means users have to scroll sideways to get the content of the page.
Because only a portion of the screen is displayed, the reader could miss instructions or drop down menus. How to Make Your Website Accessible to People Who Use a Screen Magnifier, has some good tips and a short video that shows what a screen magnifier does. The tips in the article are aimed at people in charge of websites. However, it is useful to see how it works and what happens when a site design doesn’t account for screen readers. It could help us think about the way we format documents and other information for websites.
It’s worth noting that there are around ten times as many people who use magnifiers and not screen readers, but accessibility guidelines seem to focus on readers. There is more on this topic from Axess Lab.
Making images and graphs accessible is something we can all do. Once you get into the habit it’s simple. The process is called “Alt -text” or alternative text. It provides a text alternative to documents, slide shows and web pages. The WebAIM blog site gives more detail about applying text to images. In short, it does three key things:
It is read by screen readers so it’s accessible to people who are blind or have certain cognitive disabilities.
On websites it is displayed in place of the image if the image file is not loaded or when the user has chosen not to view images.
The text description can be read by search engines.
Even if you are not in charge of your organisation’s website, any pictures you provide for web content should have your description and not be left to someone else to interpret. They might get the picture out of context. The article explains more about context.
From the Editor: I describe all pictures and images on this website. This is not the same as having a caption. Two tips: No need to start the description with “A picture of…” because the screen reader knows it is a picture or graphic and announces it. End the description with a full stop. It makes the screen reader use a tone that ends the sentence rather than sounding as if it is cut off in the middle. Also, avoid “download here” or “click here” and put the link in the actual text so the screen reader and user knows what it is referring to.