| 49 | | * |
| 50 | | * |
| 51 | | * |
| 52 | | * |
| 53 | | * |
| 54 | | *Semantic Markup — marking-up things based on what they are, not the default appearence of certain elements (eg using <blockquote>…“quoted” text</blockquote> for indentation is inappropriate. Block-quotes should be marked as <blockquote><p>…</p></blockquote> and nothing else. In this example, if indentation is required then CSS should be used to apply styling to an appropriate element (a regular paragraph (<p>Paragraph text</p>) would probably be suitable unless the element isn't actually a paragraph. |
| 55 | | * |
| | 48 | * Information Architecture — eg creating a appropriate, stable URL structure, allowing for future expansion and change (eg use of HTTP default documents rather than current practice). |
| | 49 | * Any changes to URL structure require (permanent) redirects from all previous locations to all new locations. |
| | 50 | * Valid Markup & style declarations |
| | 51 | * Should aim for HTML v4.01 Strict (XHTML served with the correct MIME-type/content-type doesn't have sufficient support, modern HTML authoring techniques are perfectly capable, adequate, suitable, and appropriate). |
| | 52 | * If Strict isn't reasonably attainable (very few reasons why apart from time constraints to correct poor design/implementation), then aim for Transitional as an intermediate step, so that the code will at least be valid. |
| | 53 | * Semantic Markup — marking-up things based on what they are, not the default appearence of certain elements (eg using {{{<blockquote>…“quoted” text</blockquote>}}} for indentation is inappropriate. Block-quotes should be marked as {{{<blockquote><p>…</p></blockquote>}}} and nothing else. In this example, if indentation is required then CSS should be used to apply styling to an appropriate element; a regular paragraph ({{{<p>Paragraph text</p>}}}) would probably be suitable unless the element isn't actually a paragraph. |
| | 54 | * Accessibility |
| 59 | | * Unobtrusive, accessible ECMAScript ( |
| 60 | | * |
| 61 | | * |
| 62 | | * |
| 63 | | * |
| 64 | | * |
| 65 | | * |
| 66 | | * |
| 67 | | * |
| 68 | | * |
| | 58 | * Unobtrusive, accessible ECMAScript (!JavaScript) use, implemented via DOM Scripting methods. [http://www.456bereastreet.com/archive/200612/you_cannot_rely_on_javascript_being_available_period/ Scripting is not always available (for many reasons, most outside the user's control) and can not be relied upon], and the back-end needs to be able to provide same functionality (albeit less elegent/sophisticated) when scripting isn't available for whatever reason. A simple example would be back-end form input validation when scripting isn't available to protect against garbage/bogus form data and provide feedback to user. |
| | 59 | * Usability |
| | 60 | * Proper navigation model |
| | 61 | * Navigation bar/panel on common pages (rather than always having to (or only being able to) go back to “Home” and then navigate to desired section from there). |
| | 62 | * Interface designer to establish the appropriate navigation options for each page. |
| | 63 | * HTTP efficiency |
| | 64 | * Content-Encoding |
| | 65 | * Providing correct Last-Modified and ETag headers to enable conditional GET requests. |
| | 66 | * Back-end support to enable “HTTP 304 Not Modified” reponses to be sent when content hasn't changed based on conditional GET request(s). |
| | 67 | * More ‘agressive’ caching for content who's frequency of change is predictable (such as images). |
