Accessible Web Design

Web is a new kind of SERVICE, not just a new technology. Before you start, you need to think through the answers to these questions:

The content of all on SED Web sites shall be related to the function and mission of the Department.

Let people know who you are; tell them what you do; explain why you do it; show them how you do it; offer what others think of what you are doing.

Every Program Area site must have a generic E-mail address. Link to an E-mail form or a "contact us" page that can be used to contact a responsible party regarding the content of the page(s).

Each SED Deputy area/Program Area shall maintain a home page and collection describing the organization and its activities. The home page will include a pointer to the SED Home Page (http://www.nysed.gov/).

Accessibility Web content publishers must ensure that all materials provided on the SED-WWW are accessible to users with disabilities, character-only, or low-bandwidth access.

Material intended to be viewed, read, or browsed online shall be prepared in HTML format (for text and tables) and GIF or JPEG (for images). GIF is recommended for graphics, line art and logos, while the JPEG format works best for photographic material where there is a need to preserve a large number of colors.

Portable document formats, such as Adobe Acrobat PDF, shall not be used as the primary format unless an HTML file is also provided. Although it is easier in many instances to create PDF than HTML and PDF preserves page layout and formatting, there are drawbacks: the contents of PDF files are not included in some full-text search indexes; PDF viewers are not embedded in most Web browsers; PDF viewers require more powerful hardware for online viewing than a Web browser alone; and PDF files present accessibility problems.

Material intended to be downloaded for offline print or display shall be prepared in one of the following formats, which are listed in descending order of preference:

File Names: Uniform Resource Locators (URLs)
URL names should use simple, understandable words and be kept as short as possible without becoming cryptic. The intent is to use names that are easy to read, remember, and type. The home.html standard should be used wherever possible as the default entry point for a directory.

URL names should use lower case. Arbitrary use of upper case (e.g., picture.GIF, myFILE.html) is prohibited. Names will not contain spaces. File names will not contain any special characters, except hyphen (-) or underscore (_). The main SED server is case-sensitive in its treatment of file names, and myfile.html is not the same as MyFile.html. Strict attention should be paid to matching actual file names with the links that refer to them.

Page Length
Like the fold in a newspaper, the bottom edge of the browser window will stop some people from reading further. If a page is only as long as the default browser window, readers will see all that is presented in a glance–and won’t have to guess what’s below the edge.

Short well-written prose with interesting links seems to attract the biggest audience. Writing for the web is not the same as writing for print. Think shorter! As a general rule of thumb, make the majority of pages no longer than 1.5 screenfuls of text to please the majority of readers. If the page is longer than 1½ screens, then a table of links, at the top of the page, will be provided.

File Size
(Adapted from Sun Microsystems Guide to Web Style)
Page length and file sizes go hand in hand. Generally, pages should be composed of no more than 100K, including images. A better way to judge whether a file is too big is to test it using the connection method that the majority of customers will be using. Estimated download times can be obtained from some HTML editors. Many customers will wait no longer than 10-15 seconds for a page to display.

Large or complex documents intended for online viewing, typically those larger than 10 screens, should be divided into multiple, smaller files. If possible, files should be divided along logical break points such as chapters or sections. To assist users in navigating sectioned documents, each page should include standard navigation buttons at the bottom with links to the table of contents and previous and next section.

Links Within Text
(Adapted from Sun Microsystems Guide to Web Style)

Write surrounding text so as to help people understand what a link does. Readers pay a time penalty for following a link. Help them understand what value they will receive if they traverse a link.

Adding a link emphasizes the word or phrase containing the link and can make the text more difficult to read. A single word may not be enough, and links that extend for multiple lines may end up confusing the reader about the destination. This example hides the useful destination of the links:

Use the default color for links whenever possible. Changing the link color can confuse users who associate "blue" with a link yet to be followed and "red" with a followed link. In addition, because users can change their browser preferences for link and background color, links set to a certain color could disappear into the background.

Cross-links within SED Site
When you add new pages to the main SED web site or another SED-funded site, remove pages, or make significant modifications, please refer to the checklist below to determine whether links should be added, revised, or removed in any of the cross-cutting categories maintained on the main SED web site.

If your information is a ...	Should this page link to it?
Major page on a hot topic or subject about which SED receives large numbers of inquiries or web requests.	Topics A to Z http://usny.nysed.gov/topics/ An alphabetical list of major topics with links to the best starting points for customers interested in finding information on one of the topics.
SED-sponsored addition or update to the web that you’d like highlighted on the main SED site.	SED Home Page http://www.nysed.gov/ Short announcement of significant additions and updates to SED web sites.
NYSED Calendar	NYSED Calendar http://calendar.nysed.gov/cgi-bin/Calcium.pl?CalendarName=NYSED_Calendar Links to selected individual event announcements.
Primary Page for SED Program Offices	Program Offices http://usny.nysed.gov/programs.html Includes links to pages for individual SED program offices.
E-mail address publicized and used for outside customers to contact a SED office, program, or service.	Contact Us http://usny.nysed.gov/contact.html Internet Working Group maintains a current list of customer service e-mail addresses the individuals responsible for each.

Every page will have a unique title. The title will be as short as possible but fully informative and specific (e.g., "FY 1996 ED Budget" is preferable to "Budget"). Although the title is often overlooked because it does not appear in the body of the document, it is important because it is frequently used to identify the document on hot lists, search result sets, and site indexes. The title also appears in the title bar of the browser.

Every page will have a top-level <H1> header or equivalent graphic banner with ALT text near the top of the first screen, except that a <H2> header may be used for continuation pages when a chapter or section is subdivided. The header should not exceed 1-2 lines of text.

Lower-level headers (e.g., <H2>, <H3>, etc.) may be used if appropriate to the document. Header markup will not be used to emphasize entire paragraphs. Generally, section titles and other text marked with the Subhead style in a word-processing document should be marked up as lower-level HTML headers instead of simply appearing in bold.

A graphic with ALT text may act as a header. Other HTML headers used on the same page should take into account the relative size of the graphic and be sized accordingly. For example, a graphic banner might replace the top-level <H1> on a page; therefore, any HTML headers used below it would be <H2> and smaller.

Additional text formatting tags (bold, italic, etc.) should not be applied to headers because they can confuse some browsers (like Lynx). Most browsers default to bold to display headers anyway. Centering the headers is OK.

Images will not be used for pure decoration. Images are appropriately used to help convey information or to create a consistent and recognizable "look and feel" for a collection. Animated images ARE NOT to be used.

Images will be as small as possible. As a general rule, images should be no wider than 480 pixels, in order to display on the typical Web browser’s 500 pixel wide viewing window on a 640 by 480 monitor.

ALT text will accompany images to make the image content available to users with text-only or screen-reading browsers. Where possible, it should express the same content as the image, for example:

Use client-side image maps and be sure to provide alternative text for each AREA of the map. If you must use server-side image maps, then provide equivalent redundant text links for all active regions of the map.

Avoid using client-specific markup. Web pages produced by SED must be usable by all browsers to ensure equitable access to the information. It is not acceptable to mark up a document in such a way as to enhance its elegance when viewed by one browser while degrading its usability under other browsers. Document authors should be aware of the variations in features available on different clients (Web browsers) and should author their documents accordingly. In general, there is substantial variation among clients in their interpretation of the HTML standard for newer, more complex features such as forms and even in some simple spacing elements such as <P>, <BR>, <HR>, and <UL>. Test the web pages for all browsers before putting them on the web.

To optimize pages for users with visual disabilities, keep the number of colors to a minimum and use color combinations that offer high contrast.

When designing pages that specify table cell background colors, designers should ensure that the pages are readable by older browsers that do not recognize this formatting. Avoid text colors that cannot be read against the overall page background color, such as yellow text on a white background.

Considerations for Users with Disabilities, Character-only, or Low-Bandwidth Access

Pages will be designed so that there is a text equivalent for all information contained in graphics.

Page designers must put themselves in the place of a visually impaired user and design pages that make sense (e.g., use "*" instead of "Blue Star" as the ALT tag for a blue star used as a list bullet). See additional guidance on ALT text in the Images section.

Place a dividing character between links that occur consecutively. Vertical bars flanked by a space are often used to prevent a list of links from being read as one long link by a screen reader.

Pages will be designed for efficient transfer over low-bandwidth connections, which are still prevalent in schools, homes, and libraries. Graphics will be no larger than necessary and may sacrifice color-depth or image resolution to reduce file size.

Online interactive forms should not replace other options. Designers will provide an alternative, such as a form to download, fill out, and mail in. Contact information will also be provided.

There are two kinds of tables, layout tables and data tables. The majority of tables on the web are layout table, used to structure the visual appearance of the page. Screen readers and talking browsers use a technique called linearizing to convert a web page to a sequence of words and lines. The assistive technology first converts images to their alternative text. Then it spreads out (linearizes) the tables a cell at a time, working from left to right across each row. If a cell of a table contains a table, that table must be linearized before moving on to the next cell. You should make sure that your pages make sense when linearized in this fashion. For data tables, there are three important techniques can be used to fulfill accessibility.

A table CAPTION is a descriptive headline for a table. The caption can appear at the top or bottom of the table.

The simple table above has a caption, "Today's Lunch Menu," which explains the table contents. After hearing this caption, reading the three heading cells and three data cells would make sense.

You can add caption to a table in FrontPage or type caption in directly in HTML. In FrontPage to insert a caption, choose Insert from the Table menu and Caption from the pop-up menu. Your pointer will be blinking at the top of the table, ready for you to start typing. If you want to switch the caption to the bottom of the table, right-click the caption and choose Caption Properties from the pop-up menu. In the Caption Properties dialog box that appears, select either Top of Table or Bottom of Table. You can format the caption text just as you would any other text on a page. If you prefer to type in Caption of the table in HTML, here is the html for the table of Lunch Menu above. Remember that the caption element has to be inside the table element.

<TABLE border="1" cellpadding="0" >
<CAPTION>Today's Lunch Menu</CAPTION>
<THEAD>
<TR>
<TH>Salad</TH>
<TH>Entree</TH>
<TH>Dessert</TH>
</TR>
</THEAD>
<TBODY>
<TR>
<TD>Caesar </TD>
<TD>Chicken Divan</TD>
<TD>Chocolate Mousse</TD>
</TR>
</TBODY>
</TABLE>

When a table is more complicated, another attribute of the table element "summary" should be used. Summary attribute is not represented visually. It is rendered from the HTML code by assistive technology like screen readers and talking browsers. It should contain a summary of what the table presents. FrontPage, unfortunately, cannot help with this attribute. You will have to type it in the code. Here is an example of "summary" for a dinner service.

<TABLE border=1
summary="This table of Blue Sky Airlines dinner service lists the five dinner courses (column headings) for each class of service, Economy, Business, and First (row headings)">

With that summary, a blind person using a screen reader (which supports the summary attribute) will have an overview of the table before he starts to read it.

Each data cell is either a pure data cell (TD) or a header cell (TH). By default, headers will appear centered in bold so that most users can easily identify them. In addition to making the headers stand out, header cells can be identified by assistive technology. You can add column and row headers using either FrontPage or direct HTML coding.

In FrontPage select the cells you want to turn into header cells, choose Properties from the table menu and cell from the submenu, or right-click the selected cell(s) and choose Cell Properties form the pop-up menu. In the Cell Properties dialog box, check the Header Cell check box and then click OK. The HTML code for cell headers is <TH></TH>.

Using the headers attribute

With the headers attribute you can specify any other cell or cells as the heading information for a given cell. You attach an id attribute to any cell you want to be a header cell. Then, add the id of each header cell to the headers attribute of a data cell. Look at the complex table below:

Travel Expense Report
	Meals	Hotels	Transport	subtotals
San Jose
25-Aug-97	37.74	112.00	45.00
26-Aug-97	27.28	112.00	45.00
subtotals	65.02	224.00	90.00	379.02
Seattle
27-Aug-97	96.25	109.00	36.00
28-Aug-97	35.00	109.00	36.00
subtotals	131.25	218.00	72.00	421.25
Totals	196.27	442.00	162.00	800.27

Here is sample HTML marking up the data cells for this table with the headers attribute. We have used the convention that c1, c2, c3, ... are the id's of the column headings and r1, r2, r3, ... are the id's of the row headings.

<TABLE border="1">
<CAPTION>Travel Expense Report</CAPTION>
<TR>
<TH></TH>
<TH id="c2">Meals</TH>
<TH id="c3">Hotels</TH>
<TH id="c4">Transport</TH>
<TD id="c5">subtotals</TD>
</TR>
<TR>
<TH id="r2">San Jose</TH>
<TD></TD>
<TD></TD>
<TD></TD>
<TD></TD>
</TR>
<TR>
<TD id="r3" >25-Aug-97</TD>
<TD headers="c2 r2 r3" bgcolor="#ffff00">37.74</TD>
<TD headers="c3 r2 r3">112.00</TD>
<TD headers="c4 r2 r3">45.00</TD>
<TD></TD>
</TR>
<TR>
<TD id="r4">26-Aug-97
<TD headers="c2 r2 r4">27.28</TD>
<TD headers="c3 r2 r4">112.00</TD>
<TD headers="c4 r2 r4">45.00</TD>
<TR>
<TH id="r10">Totals</TH>
<TD headers="c2 r9">196.27</TD>
<TD headers="c3 r9">442.00</TD>
<TD headers="c4 r9">162.00</TD>
<TD headers="c5 r9">800.27</TD></TR>
</TABLE>

The highlighted cell with the value 37.74, for example, is associated with the date "25-Aug-97" (id="r3"), the city "San Jose," (id="r2") and expense item "Meals" (id="c2"). To make it readable, the subject cell is coded:

Assistive technology might then read this cell "Meals, San Jose, 25-Aug-97, 37.74" or "37.74, Meals, San Jose, 25-Aug-97."

Designing web pages with frames enables the display of multiple scrollable panels on a single screen, each with its own distinct URL. Frames divide web pages into separate regions that can display content independently. However, frames present navigation and accessibility problems. They typically don’t work as well on low-resolution screens because the content must be compressed into smaller frames. And because they require multiple page loads, they can also increase download time. If after a careful consideration of these problems, a web publisher chooses to employ frames, an alternative accessible non-frames version will be required, both as a default for browsers that do not support frames and as a prominent link users may choose from the frames version.

After a document has been marked up but before it is made publicly available, the spelling and syntax should be checked, and the links should be verified. HTML converters can insert unnecessary code when converting or marking up a document. Because reading duplicate or unneeded code can increase file size and slow file loading, web publishers should give their documents a "cleaning" before they are posted.

Some SED Internet Tech Standards & Guidelines