I was responsible for most of the programming beneath the navigation bar on the home page, and every time when I book a ticket there’s a small feature I enjoy so much I want to tell you about it: the buttons on the date selector are really, really tiny (16 × 8px). As you know thanks to Fitt‘s Law, there are even formulas to calculate how much better big buttons can be hit.

So I just added some padding. And that makes a huge difference: try to click on the same buttons later on in the booking process where the padding is missing.

If I could make one improvement I would add keyboard functionality to those buttons. Alas as the datepicker itself came from a third party, the assembled code was beyond my control. But I know that the Deutsche Bahn is listening to the needs of people with disabilities and their disability advisory board members are highly competent, so I trust these and other issues will be fixed soon …

Most rollovers have become obsolete because they can be performed on background images with CSS sprites. If there are hover effects today, they usually come as text on a button background image, or as a text link with an icon next to it.

However, there are those rare cases when there is just an icon without text, like a “play” or “pause” button, or a magnification glass on an image to signal it can be enlarged. If you want to swap images when the element receives focus or on mouseover, traditionally you are stuck with two options:

1. JavaScript to change the image source, or
2. CSS sprites to change the position of a background image behind a transparent gif image.

I like neither. Using JavaScript and two images with pre-loading seems like a waste of resources when it can be done with CSS and one image only. Transparent gifs are so 1998, besides the background usually doesn’t get printed. So what we need on these occasions are CSS sprites for foreground images.

Until recently I thought that can’t be done, but then I stumbled upon some code for checkbox widgets in Dojo. Naturally they use a lot of JavaScript for the task. Anyway I like my default checkboxes and don’t have any urge to make them prettier (I have no doubt our design overlords would enforce aqua icons everywhere), but that made me think. Here’s a suggestion:

First a simple sprite which is 50px wide:

The HTML code uses the dimensions of a single icon for width and height to allow fast page rendering without reflow:

1. <a href="/big/" class="icon">
2. <img src="/img/icon-enlarge.gif" id="magnifier" width="19" height="15" alt="enlarge image" />
3. </a>

The corresponding CSS sets the link to display: block, uses the single icon dimensions for the container, prevents overflow, and resets the image dimensions to auto to prevent distortion. The actual image swapping is achieved by a negative left margin on hover.

1. a.icon {
2. display: block;
3. width: 19px;
4. height: 15px;
5. overflow: hidden;
6. }
7. a.icon img {
8. width: auto;
9. height: auto;
10. border: none;
11. }
12. a.icon:hover img, a.icon:focus img, a.icon img.hover {
13. margin-left: −31px;
14. }

For the sake of simplicity I ignored how the link would be floated or positioned. Also borders, a background color, or padding to increase the clickable area can be added to the parent element.

For simplicity I chose a link in the example, but the same can be done with a div surrounding an <input type="image" />. Then of course you need to define cursor: pointer, and for anything below IE7 bind the DOM event to the hovering element (get the source):

1. <!--[if lt IE 7]>
2. <script type="text/javascript">
3. oIcon = {
4. setHoverClass : function() {
5. this.className = 'hover';
6. },
7. resetHoverClass : function() {
8. this.className = '';
9. }
10. };
11. var elm = document.getElementById('magnifier');
12. if (elm) {
13. elm.onmouseover = elm.onfocus = oIcon.setHoverClass;
14. elm.onmouseout = elm.onblur = oIcon.resetHoverClass;
15. }
16. </script>
17. <![endif]-->

Here is a working example. You know how to adjust the code if you need more than one class on the image.

That was nice and easy. It’s tested in Firefox 2, Opera 9, Internet Explorer 5+, and Safari 2. Screen readers should be okay with the alt text.

Discussion

The trouble begins when people start turning off browser features.

People with disabled images won’t be able to read the alternative text because the visible area is limited by the parent container. That can be detected by comparing the known sprite size with the alt text size. Then the class is set to anything but icon so that the parent container expands.

More severe is when people disable style sheets because then they will see a squeezed image with multiple icons. If you are hyper-correct, you could replace the crushed multi-icon image with the correct single icon (you could use the class or rel attribute to define the icon type), but nobody wants to slice images. As a compromise I would suggest to replace the icon with its alt text.

See the script to detect disabled images or CSS. (Note: it isn’t implemented here because I couldn’t test it properly on IE6 with stuff turned off.)

If JavaScript is unavailable, the user is stranded with what we gave him. Also icons without text are inherently evil because they can’t be enlarged by zoom readers. Did I forget any politically correct disclaimer for obscure use scenarios?

So we ended up with a CSS only version, but still some JavaScript is needed for the extra effort to provide the same experience to users of IE 5-6, and some more for certain user scenarios. Wouldn’t it be easier to slice and swap foreground images the old way? But then again slicing is a pain, and people already start using background images. Do people actually turn off CSS and images? Or is that another remnant of WCAG 1.0 from 1999?

Matrix of supported browsers in BlueMars projects

“Expecting two users using different browser software to have an identical experience fails to embrace or acknowledge the heterogeneous essence of the Web.”

Nate Koechley introduced Yahoo!’s smart concept of graded browser support nine months ago. Until then we did test a lot of browsers, but all browsers were supported equal. Now came this man who suggested distinctions, a graded instead of a boolean or binary support.

• There is a blacklist of C-grade browsers. They are antiquated, but core content and functionality should work in them. Never mind the design though, as some of them do not support CSS 2. Semantics and good accessibility are more important and tested by QA.

• Then there is a whitelist of advanced (A-grade) browsers supporting modern web standards. QA tests these browsers, and bugs are handled with high priority.

• The rest of the unknown or rare browsers are X-grade. It is assumed they support modern web standards, but it would be inefficient and impossible to test them.

That’s a very pragmatic and efficient framework since it adds scalability for QA.

Almost unnoticed were two updates of the browser matrix in August and a couple of days ago where Opera 8 got replaced by Opera 9, also support for Internet Explorer 5.5, Safari 1 and Firefox 1.0 has been discontinued because they are vanishing species. Support for Firefox 2.0 has been added, while Mozilla suite has been terminated since there are virtually no differences between Firefox and Mozilla suite.

Our own matrix includes Konqueror, but otherwise it’s more or less the same as the current Yahoo! browser matrix, although we do not test rare Windows versions like Windows 98 or 2000. Here is the adapted matrix we use in our own projects. Do you think that’s a reasonable approach?

Matrix of supported browsers in BlueMars projects

• Introduction
• Differences between WCAG 1 and WCAG 2
• What’s wrong with WCAG 2?
• Discussion
• Conclusion

Introduction

His article “To Hell with WCAG 2” was an eye-opener. Joe Clark expressed his angriness about the W3C, its slow, lobby-driven, bureaucratic processes, the gruelling internal fights within working groups and the Web Accessibility Initiative (WAI) in particular. The WCAG 2.0 Working Draft was a disappointment, basically unreadable, impossible to understand, and failing in major issues after five years in the making (WCAG 1 took a little longer than two years to become a finalized standard).

At that time I hadn’t read WCAG 2 yet. Joe Clark’s passionate article was a revelation, and all the blogs I read agreed with him. Perhaps I wasn’t the only one who hadn’t read the working draft by then. Because now I have, and while there are some valid points in his inflammatory speech, there are also major flaws.

Did you know that, contrary to Joe Clark’s beliefs, validating code is a requirement? That semantic markup is enforced? Other issues are totally overrated, like claiming a decent tab order was equal to the “prohibition of CSS layouts.” But more on that later.

His assault on the W3C set a spark to the tinderbox, and suddenly we heard concerns confirming the bad state of the Consortium from respected celebs like Jeffrey Zeldmann, Molly Holzschlag, Eric Meyer, Björn Höhrmann, and Tim Berners-Lee, to name a few.

Clark’s public criticism might be seen as a bold and important step. However, actually calling group members “arrogant and ignorant,” hanging up during conference calls and allegations like “some teenagers have greater understanding of valid, semantic markup than the Working Group” (ibid.) hurts the cause. If you search the WAI mailing list for more contributions from Joe Clark, you will immediately notice his egocentric, cynical, and often insulting style. He criticizes ignorance and harassment within that working group, but he’s part of the problem.

Meanwhile some things seem to go right at the W3C: the I18N activity led by Richard Ishida, or the quick embracing of Microformats, Web Forms, Widgets and Gadgets, and the XHTML 1.1 Role Attribute Module.

The latter has to be seen in context with IBM’s contribution to the Mozilla source code for DHTML accessibility. To implement that important technique, IBM has proposed an extension of the HTML specification to allow a negative tabindex. Joe Clark overstates that simple extension as “IBM actively promoting a DHTML technique that breaks the HTML specification.”

Differences between WCAG 1 and WCAG 2

WCAG 2 introduces four basic principles of accessibility. Content must be POUR:

1. Perceivable
2. Operable
3. Understandable
4. Robust

The guidelines are organized around these four principles, and checkpoints for the guidelines are now called success criteria. Each success criterion comes with an extended commentary, techniques to meet the guidelines, and common failures. That’s more comprehensive than version 1 and leaves less room for ambiguity.

The success criteria for each guideline are organized into three levels, though not all guidelines contain success criteria at every level. Levels are like WCAG 1 priorities, but they are more precise. WCAG 1 checkpoints had only one priority allocated, while a success criterion with multiple levels can be more differentiated.

In the past programming a website to conform to level triple-A was an almost impossible and disproportionate effort. Besides guidelines always have room for interpretation, so it is possible that experts disagree if a criterion has been met. Therefore the working group was pragmatic enough to grant triple-A conformance if at least 50% of all level 3 criteria are fulfilled.

Techniques for a website are defined in a public baseline, like “the specification that this content relies upon is: XHTML 1.0 (Strict). The specifications that this content uses but does not rely on are: JavaScript 1.2, CSS 2.” You can specify any reasonable technique, there’s no longer a preference for W3C techniques — if Flash is accessible enough and sufficient for the job, you don’t have to use SMIL. More on the baseline concept later. In the same way your conformance claims and conformance scope are published.

Since the working group tried to be as generic as possible, some terms changed. They speak of “web units” instead of “pages”, because web units include things like Ajax applications, which wouldn’t be covered by the term “page.” You get used to the terms fairly quick.

The guidelines were extended to be less ambiguous and include more cases. Deeply hidden within the documents are some true gems, for example accessible CAPTCHA or accessible Ajax. Wonderful!

What’s wrong with WCAG 2?

The information is yet too scattered among different documents, which makes it hard to read and comprehend. However, the working group notes it’s still work in progress, and they want to create separate files for each success criterion as well as a navigation structure. That sounds like the commented German accessibility guidelines, so I’m positive that the end-result will be more usable.

I must admit it could also be more readable. A professional copywriter could help, but I can imagine the exact wording of each success criterion was probably a big issue in WAI meetings, so the stakeholders won’t give up so easily just for enhanced readability.

Speaking of comprehension and easy reading, severe flaws can be found in the cognitive department. “Making text content readable and understandable” is a joke. Guidelines for context and orientation, navigation, and comprehension have been more or less dropped since WCAG 1.

We’ve come a long way to understand these features are not for cognitively challenged people alone, but they are basic requirements for all of us. Young people with insufficient reading skills, elderly who are new to the Internet — we all benefit from features like breadcrumb paths, a consistent navigation with clear wording, well written text, or relevant search results. These guidelines spell usability! We can’t allow having them removed!

Discussion

His article raised critical awareness for the last-call W3C working draft, which lead to the extension of the comments period. Still the degree of concern and fear didn’t need to be raised. Many issues are exaggerated, distorted by omission, or plain wrong. Let’s discuss them in detail:

1. 1. Definitions of “page” and “site”

   Exactly what a “page” is, let alone a “site,” will be a matter of dispute.

   Agreed. Although everybody knows what these terms mean, a formal definition is missing. But there are more important issues. That’s a typical Joe Clark.

2. 2. Valid (X)HTML

   A future website that complies with WCAG 2 won’t need valid HTML — at all, ever. (More on that later.) You will, however, have to check the DOM outputs of your site in multiple browsers and prove they’re identical.

   Not true. Success criterion 4.1.1 in plain English demands that IDs must be unique and elements properly nested. One technique to ensure that is validation. How was it possible that Joe Clark missed such an important point? Had he actually read his printouts, or was he just summarizing his correspondence with the working group?

   However, it is true that a comparison of DOM outputs is seen as an alternative technique to ensure proper nesting or well-formedness. That won’t work. Even valid code doesn’t result in identical DOM outputs in multiple browsers. Take for example line-breaks and code indented with tabs (white-space): Mozilla counts these as text-nodes, while IE ignores them in the DOM tree. Besides it would be a tremendous effort to compare the trees manually. Would somebody please create a validation tool with different browser engines under the hood?

3. 3. Table layout

   You can still use tables for layout. (And not just a table — tables for layout, plural.)

   Of course we know the disadvantages of table layout, and they are a pain to every standardista. From a pure accessibility standpoint they are tolerable as long as they can be linearized and semantic markup like <th> isn’t misused. But speaking semantically, isn’t a <td> supposed to represent tabular data?

4. 4. Blinking elements

   Your page, or any part of it, may blink for up to three seconds. Parts of it may not, however, “flash.”

   Everybody hates the infamous blink tag because it makes text unreadable. But I don’t think that’s what they are speaking of. It’s more like in banner ads, or in Ajax notifications. For three seconds I can live with that. The difference between blinking and flashing is the frequency; the latter can result in epileptic seizures. Simply avoid anything between three and fifty flashes per second.

5. 5. Baseline technologies

   You’ll be able to define entire technologies as a “baseline,” meaning anyone without that technology has little, if any, recourse to complain that your site is inaccessible to them.

   Not true. Baselines have to be reasonable. If they are not reasonable, others, including your government, can set a baseline.

   There are a couple of examples for reasonable baselines, like “only technologies that have been widely supported by more than one accessible and affordable user agent for more than one release” for a government site. More examples can be found in the …

6. 6. Conformance claims

   If you wish to claim WCAG 2 compliance, you must publish a checklist of declarations more reminiscent of a forced confession than any of the accessibility policies typically found today.

   Hmm, which of the following do you think is clearer?

   1. 

   2. On 5 May 2006, “G7: An Introduction” http://telcor.example.com/nav/G7/intro.html conforms to W3C’s WCAG 2 Conformance Level Double-A. The following additional success criteria have also been met: 1.1.2, 1.2.5, and 1.4.3. The baseline for this claim is UDBaseline#1-2006 at http://UDLabs.org/baselines#1-2006.html. The specification that this content “relies upon” is: XHTML 1.0 (Strict), and Real Video. The specifications that this content “uses but does not rely on” are: JavaScript 1.2, CSS 2.

   My vote goes for the WCAG 2 conformance claim. Include this elegantly as a RDF file within a <link> (something missing in this working draft), and I’m a happy developer.

7. 7. Conformance scope

   You’ll be able to define entire directories of your site as off-limits to accessibility (including, in WCAG 2’s own example, all your freestanding videos).

   That’s true. But you can’t exclude integral parts of a process, like parts of a shop, though further definition would be required which parts can be excluded and which can’t. It becomes clearer when you take an example where the scope is set with a date:

   Materials with creation or modification dates before 31 December 2006 conform to WCAG 1.0 Level Double-A. Materials with creation or modification dates after 31 December 2006 conform to WCAG 2.0 Level Double-A.

   I can imagine cases where new content does conform to WCAG 2, while nobody bothers to touch really old content somewhere deep in the archives. So scoping is a practical issue: rather have conformance for the new and important parts than none at all.

8. 8. Video

   Not that anybody ever made them accessible, but if you post videos online, you no longer have to provide audio descriptions for the blind at the lowest “conformance” level. And only prerecorded videos require captions at that level.

   Joe Clark was dubbed the king of closed captions, so from his point of view WCAG 2 must be a step backwards: audio descriptions for prerecorded video are required on level 2, on level 1 either audio descriptions or a transcript will be sufficient. Audio descriptions for live video content were dropped in November 2005, and captions for live videos are level 2.

   WCAG 1 was very vague and didn’t make distinctions between live and prerecorded video. Everything had to have audio descriptions on the lowest level. The WCAG 2 approach doesn’t go that far. Although this might be disappointing, it is more differentiated and more reasonable.

9. 9. Audio

   Your podcasts may have to be remixed so that dialogue is 20 decibels louder than lengthy background noise. (You don’t have to caption or transcribe them, since they aren’t “multimedia” anymore. […]

   I agree not many people have the equipment to correctly measure a difference of 20 dB(A), but as a rule of thumb any dialogue should be easy to understand. Having my own program on a free radio station I can dig that. But there’s another major point Joe misses: although technically audio only is not multimedia, it still has to be transcribed.

10. 10. Skip links

    You can put a few hundred navigation links on a single page and do nothing more, but if you have two pages together that have three navigation links each, you must provide a way to skip navigation.

    Skip links are good, I don’t mind to have them everywhere. But in WCAG 1 “a few hundred navigation links” would have been required to be structured with subheadlines to enhance understanding. That’s the real issue here!

11. 11. Offscreen positioning

    You can’t use offscreen positioning to add labels (e.g., to forms) that only some people, like users of assistive technology, can perceive. Everybody has to see them.

    Although the intent of that criterion clearly is to make structure available to screen readers through semantic markup, the sentence Joe Clark refers to could be interpreted the way he does. Here’s the original:

    The purpose of this success criterion is to ensure that when such relationships are perceivable to one set of users, those relationships can be made to be perceivable to all.

    That’s not really new. Think of zoom readers with tab navigation via keyboard. If you place content offscreen, it can be quite irritating if an element gains focus and still is not visible. Good practice would require at least changing the element’s position to a visible area when it gets :focus. Although labeling forms, like in Joe’s example, can be achieved without offscreen positioning since the title attribute is deemed sufficient.

12. 12. Tab source order

    CSS layouts, particularly those with absolutely-positioned elements that are removed from the document flow, may simply be prohibited at the highest level. In fact, source order must match presentation order even at the lowest level.

    Death to any order columns! Death to the Holy Grail! I can understand the feelings some have towards that, but again it’s nothing new. In fact, in Germany’s eAccessibility law it was implemented as a priority 2 feature, not 3. The tab navigation shouldn’t be irritating and jump across the page, so take care of your source order.

13. 13. Idioms, acronyms, and pronounciation

    Also at the highest level, you have to provide a way to find all of the following:

    1. Definitions of idioms and “jargon”
    2. Expansion of acronyms
    3. Pronunciations of some words

    While for English developers marking-up foreign-language passages might be an exception with an unusual amount of “fanatical care” to achieve this, people in countries like Japan or Germany, where you have many anglicisms especially in technical texts, had a long time to get accustomed to it.

    In fact, according to WCAG 1 any language changes had to be identified as a priority 1 requirement, while in WCAG 2 only the document’s primary language is level 1, and only passages or phrases within the text are level 2, not single words. This is an incredible work reduction. Considering screen readers make a subtle pause before language switches that can get annoying in texts with many foreign words, it is also an improvement for those users.

14. 14. Alternate documents

    You also have to provide an alternate document if a reader with a “lower secondary education level” couldn’t understand your main document. (In fact, WCAG 2 repeatedly proposes maintaining separate accessible and inaccessible pages. In some cases, you don’t necessarily have to improve your inaccessible pages as long as you produce another page.)

    Again, that’s an old friend, and it’s emphasized that an alternate version “is a fallback option and is not preferable to making the content itself accessible.” So what? If a technical document for a specific target audience can’t use very simple language, it is common to provide a text summary for people with lower reading skills. That doesn’t mean we forget about accessibility and start publishing nothing but alternate text versions again.

Conclusion

Joe Clark takes some points, but on a closer look his article leaves a bitter taste as another tool for enforcing his point of view on the Web Content Accessibility Working Group. Okay, probably most of us who care about web standards today have been nerds as teenagers. But then again most of us have quit playing Dungeons and Dragons and got some social life. We don’t spend hours in front of our TV and write angry nitpicking letters to the CBC. We don’t harass W3C working groups, and when they won’t be intimidated, we do not found our own. Be gentle and play with the other kids.

If you want reform then do it from the inside — the subtlety of subversion is more effective than revolution.

Comment on Eric Meyer’s blog

WCAG 2 is not so spoiled, there’s still plenty of opportunity to make your constructive critique heard until the working draft becomes a recommendation.

Thanks to the Frankfurt Webmontag for the inspiration to write down and extend the things I mentioned in my lecture about WCAG 2 on 14 August 2006.

In this article:

• Case study
• Best practices in HTML
• Best practices in CSS
• Best practices for search engines

Case study

Over the years we made several technical analyses for the clients’ own websites and some of their competitors, including major German broadcasting companies, TV program journals, and a couple of large online travel sites.

We were checking for overall performance like file sizes as well as best practices in (X)HTML, CSS, semantics, and some other aspects of friendliness to users and search engines. We mostly skipped accessibility because there were already severe errors in the other areas.

It’s not like these websites were made by some backstreet crack houses agencies. All have a well-known logo stuck to them, most of them get more than a million visits each month, some up to more than a hundred million. Still the reviews felt like a time-travel to 1998. In our elite circles we speak about a “new professionalism,” but HTML in the wild is still a very dark and ugly jungle.

Most common errors were missing alt-attributes and unencoded &-characters in URLs. Also quite common were XML endslashes in HTML documents, or hacks from the nineties: proprietary attributes like background in table data, height in a table row, marginwidth, marginheight, topmargin and leftmargin, or missing type attributes in style and script tags.

Getting into the depths of old-school programming we found proprietary tags like <nobr>, <ilayer>, or <spacer>, misconceptions like valign="center" instead of "middle", forgotten closing tags, or tag soup like the classic form between table rows (to prevent top margins), block level elements inside of inline elements, <p> tags around everything (including tables and headlines!), or script tags before or after <html> </html>. Especially ad servers and site statistics were infamous for their crappy stone-age code.

Only a few were missing a doctype declaration (DTD) altogether, most ran HTML transitional 4.01 in quirks mode, only one claimed to be XHTML 1.1 (gasp). Seven out of ten had a charset encoding, but only the XHTML website did care to define the site’s language. Almost all had no clue about CSS positioning and used table layout.

Sometimes we encountered code where developers obviously hadn’t understood even the most basic principles of CSS 1. They used either font tags with style attributes, or other tags just like font tags with a lot of repeated inline style. Thus the advantages of CSS through central style sheets with classes and IDs were counteracted.

It didn’t come as a surprise that the few websites using CSS 2 for layout had significant smaller file sizes. Those with CSS 2 had between 15-21 KB of HTML, their competitors with table layout 55-95 KB. Still you got to pay attention to the file size of images and rich media (including banners) as they frequently blow up the total amount. Be aware of DHTML menus, as they have a tendency to get out of control sizewise (40k JavaScript in one case, 85k in another). Less than a total of 100k for the home page should be sufficient, even for sites with rich graphic interfaces.

I don’t want to bore you with further rants about burning bandwidth with 600k large home pages (multiply that by a million), hence we thought positive and made a checklist of best practices. Although the checkpoints appear to be quite obvious and common sense when you read them, you might be surprised that the best website managed to fulfil 22 out of 29 checkpoints, the worst only 8, with an average of 12.

By the way, the HTML and CSS part of the checklist is more or less the same we use for testing the qualifications of job applicants. We associated a severity grade (major, average, minor) with each checkpoint, and for each error in the small task we give them we subtract 3, 2, or 1 point(s) respectively from a maximum of 100. Half the amount is subtracted when a checkpoint is partially fulfilled. We adopted that system from the German accessibility test — it’s fair and a great way to compare test results.

Here’s the short version of our checklist. Feel free to make your own severity rating. Just be consistent in your own tests to get comparable results.

Best practices in HTML

1. The document must validate as HTML or XHTML.
2. The document must have a DTD.
3. The document must have a character encoding, either through a HTTP header or a meta tag.

4. The document should have the language defined in the following ways:

   • <html lang="en">
   • <html xml:lang="en">
   • <meta name="content-language" content="en">
5. All attribute values should be quoted. In XHTML, quotes are mandatory.
6. Element and attribute names should use a consistent case to enhance readability, preferred is lowercase for XHTML compability.
7. Code should be well <!-- commented --> to help maintaining developers to get a fast grip of the basic structure and key concepts.
8. Code should be consistently indented, tabs preferred over spaces.
9. Images, image maps and scripted content must have an alt-attribute with an appropriate value.
10. Images should always specify their width and height to allow browsers to continue rendering while waiting for the image data.
11. Some special characters like ", <, >, and & (especially within attributes like href or src) must always be replaced by their character entities or numeric character references (NCR). Also characters not included in the character set, like € in ISO 8859-1, must be replaced. The W3C I18N activity group further recommends to replace other special characters like –, but not common characters like “ü” in German texts or “é” in French to maintain code readability.
12. script and style tags must have a type attribute.

13. JavaScript code should be included using external files for caching and better maintenance.

    Of course with Yahoo’s performance research about browser cache and HTTP requests you could discuss if external files load faster with several server requests through script src="foo.js" or just one request and internal HTML code, but either way you should use central, non-redundant files and include them in one way or another.

Best practices in CSS

1. CSS must validate.
2. Elements should be positioned with CSS 2, not tables.
3. All ornamental lines, borders, background colors and -images, underlines and other decorational elements should be rendered with CSS 2.
4. Text should be formatted with CSS 1, not with font tags.
5. All style sheets should be included in reusable, centrally maintainable, and cacheable external CSS files, not as redundant code within the HTML files.
6. External CSS files should be sent with the correct MIME type (text/css).
7. CSS classes and IDs must be valid, i.e. beginning with a letter, not a number or an underscore. IDs must be unique. Their names should be generic, describe functionality rather than appearance.

Best practices for search engines

1. Use a descriptive title with the name of the website and consistent separating characters in it.
2. Use keywords, keyphrases, and a description reflecting the page’s content.
3. The URL should be descriptive, human-readable, easy to remember, to bookmark, and easy to spell on a phone. Don’t bother the user with file extensions, thus you will be future compatible and independent from your current software.
4. Use the Robots Exclusion Standard, i.e. robots.txt.
5. The content should be as high up in the code as possible as it gets more relevance there.
6. Use proper semantic code, like headlines, or list items for anything that resembles a list. Don’t use list items to get bullet points or headlines to set bold text.
7. Use <link> tags to specify relations between pages, like rel="start", chapter, prev, or next, as search engines might value your start page more, or browsers could preload next pages.
8. Use a favorite icon for bookmarking and to keep your error log clean.
9. Use the PICS standard to signal search engines and filter programs that your website is safe for kids.