A Basic approach to Building an Accessible Web Page
Accessibility
5th May 2010
Semantic HTML
My basic approach when I begin building a web page is to plan the structure of the page, and represent it from the beginning using semantic html. The elements that I decide to use and the order that I use them in should accurately reflect the content that they will represent. The HTML should never be used to artificially apply any presentation to the content e.g. an <h4> element should not be used to embolden text, but rather a font-weight style should be applied.
By planning the correct structure from the outset, we immediatley begin to make the page more accessible to screen readers that rely on the HTML to convey the correct information.
Having created a skeleton page, I view the page under different browsers to ensure it is usable and I validate the HTML using the W3C HTML validator tool.
Applying Styles Using CSS
The next step is to apply styles to the page. I always use an external styleheet where possible as it easier to maintain and represents a more scaleable approach. It is also more effective in seperating the structure of the page from the presentation layer that determines how it is displayed.
There are a number of accessibility issues to consider
- How will the page appear at different screen resolutions?
- Can the user resize the text whilst maintaining a usable layout?
- Can the page be viewed without a style?
- Can the page be viewed without images?
- Can the user apply their own styles without interference?
- Is there sufficient contrast on the page?
The priority associated with these potential issues will depend on the projected audience for the site. It is impossible to make any website completely accessible to everybody, but we must try and make it as accessible as we possibly can to the majority of expected users.
Using Relative Units for Sizing
By applying relative size units to text and other page measurements, the layout of a page will remain more consistent at different resolutions and text sizes. Relative units include:
- EM
An em is a unit of measurement in typography. It was traditionally the width of the capital M in the font that is currently being used, thus it it is relative to the chosen font.
- Percentages
Percentage values are always relative to another value. That value may be another property for the same element, a property for an ancestor element, or a contextual value e.g. the width of a containing block.
- Pixels
The W3C CSS2.1 Specification (and the CSS3 working Draft) lists the pixel as a relative unit, but there is some debate as to whether it should be treated as such in context of an accessible layout.
The pixel is relative to the resolution of the viewing device so I tend to use them for border sizes, paddings, margins etc. However, I would always use a percentage or an em etc for setting a font-size as these units are relative the users font settings.
The fact that a px is relative to the viewing device may cause issues on mobile user agents where the viewing port is very different to a computer display. A mobile stylesheet that applies a single column with a width of 100% can circumvent this.
Applying a Flexible Layout
It is also possible to use CSS to alter the layout of a page depending on the resolution by applying a flexible fixed layout. For example, a 3 page layout can change to a 2 page layout at lower resolutions by manipulating the CSS so that the 3rd column moves beneath the first column. In this way we can avoid a horizontal scrollbar and the page remains usable at lower resolutions.
Testing
By planning the page initially using only semantic HTML, it should always be possible to view the page without styles. It is alos important that web developers and designers do not set up their pages to interfere with or override any user-defined sylesheets. The contrast on a page should also be considered - users should be able to distinguish the text on a page from any background colours or images. Colour blind users should also be accounted for where possible.
At this point I would revalidate the HTML and also use the W3C CSS validator to check the CSS. A number of tools are available for assesing the accessibility of a page, but the one that I use is the WAVE toolbar extension available for the Firefox browser. A Colour Contrast Analyser by Gez Lemon is also available as an Add-on for Firefox.
As well as the automated tools I also test the page against various version of different browsers at different screen resolutions and text sizes. this is an iterative process where I continually revisit the HTML and CSS until I am happy with the result.
Client Side Scripts
Once I am happy with the usability and accessibility, I add any required enhancements using progressive scripting. I ensure that there are no script errors and then test the new functionality again using a variety of different browsers at different resolution sand text sizes.
I again revalidate the HTML and the CSS and retest.
Screen Readers and Text Only Browsers
The final step is to test the pages using a text only browser and at least two screen readers.
The text only browser that I use is LYNX and the screen readers that routinely use are:
- Windows Eyes
- JAWS
Demo versions of both these tools are available from
Lynx
Text only browsers do not support graphics, or technologies such as CSS and Javascript. They can therefore give a good usability overview of a page with these technologies turned off. The Lynx text browser can be downloaded as a standalone application, or the url of the site to be tested can be submitted to the Delorie Lynx Viewer website and a view of the page as if it were viewed in Lynx will be displayed.
Command keys are primarily used to navigate the user interface of the standalone application
- G(Go) allows a URL to be entered
- O(Options) allows the setting of user preferences
- The down arrow ↓ moves through the links on a page
- The right arrow → will follow a link
- The left arrow ← returns to a previous page
- Page Up and Page Down move you throught the various screens
Windows Eyes and JAWS
All screen readers have a specialised web mode for reading web pages and active elements on a page e.g. links, form controls can be navigated using the Tab key (Shift + Tab moves the user backwards through the document). The tab sequence will follow the HTML structure of the page unless a tabindex attribute has been specified.
Windows Eyes
- The web mode in Windows Eyes is called Browse Mode or MSAA Application mode
- The Esc or Ctrl key will stop speech synthesis
- Ctrl + Home returns you to the start of the document
- Ctrl + End takes you to the end of the document
- Ctrl + Shift + R will read from the current point to the end of the page
- L will navigate through the links on a page (Shift + L to move backwards)
- H will move from heading to heading (Shift + H to move backwards)
- C will find Form controls on a page (Shift + C to go backwards)
- To input text into a field, you must leave Browse mode by pressing Enter when a Form control has the focus.
- Ctrl + Shift + A will return you to browse mode.
JAWS
- The web mode is known as Virtual PC Cursor (VPC) and is toggled on and off using Insert + Z.
- The Ctrl key will stop speech synthesis.
- The down ↓ and up ↑ arrows will move to the next and previous lines.
- Insert + ↓ down Arrow will read from the current location to the end of the page.
- H will jump through the headings on a page (Shift + H) to go backwards.
- Ctrl + Insert + Home will find and read the first form control
- F will then move you through the form controls (Shift + F to go backwards)
- You need to press Enter to enter Forms mode to actually input text.
- You use the + key on the numeric pad to leave Forms mode and re-enter VPC mode.
- Ins + F7 will open JAWS link list that displays all the links on the page.
- Other lists available: Ins + F5 (Form fields), Ins + F6 (Headings) and Ins + F9 (Frames)
Mark