XHTML Integrity Standards v2.0
1.1 This standard describes the requirements to which you MUST adhere when coding BBC sites UNLESS you are maintaining an old site that uses Barley.
1.2 This standard also features other requirements and recommendations related to the general building of web pages.
Top of page
2. Doctype and validation
2.1 A Doctype MUST be included, and the Doctype used MUST be either:A1
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd"<
2.2 The page MUST validate against one of these doctypes using the W3C validator.A2
2.3 You MUST put the DTD on the first line of the document, to enable standards mode reliably.A3
2.4 You MUST NOT specify an xml prolog; that is,
2.5 You MUST specify the following xml namespace for the document in the html:A5
Top of page
3. Legal and compliance
3.1 The BBC has statutory obligations, in terms of the Disability Discrimination Act (DDA), to produce accessible content. For details of this see the Accessibility Standards and Guidelines.
3.3 If you wish to use sIFRs on your site, you MUST apply for an exemption from your product lead. Refer to the Textual Equivalents Standards for further information.A7
3.4 You MUST NOT use server-side imagemaps, as they are not accessible.
3.5 Applications that process personal data MUST conform to the requirements of the Data Protection Standard, see also the Email standard.
3.6 Anyone wanting to host a site externally via a third party MUST apply with a business case to the Information Security Manager. Please see the Third Party Hosting Standard.
3.7 You MUST provide a credit to the company or individual when using copyrighted code. Otherwise no individual names or company names should appear in your comments.
Top of page
4. Browser support
4.1 The BBC supports certain browsers, as listed in the Browser Support Standard. You MUST write your XHTML so that your pages work in all level 1 and level 2 supported browsers.
Top of page
5 Character sets
5.1 You MUST have one, and only one, character set for the document.A8
5.2 When specifying the character set of the document, you MUST use
UTF-8. International pages MAY use
UTF-32 if necessary, it SHOULD be noted though that these character sets can significantly increase the overall size of your HTML.
5.3 All new publishing systems MUST output as
UTF-8. Some legacy systems and third party feeds can have outputs that are not
UTF-8 which can cause conflicts; in this case the output MUST be converted.
5.4 You MUST set the character set and mime-type in the head of the document like so:A9
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
5.5 You MUST serve the file from the server with
UTF-8 encoding (N.B. The html file will be served as text/html).
Top of page
6. Supported languages
6.1 You MUST specify the base language of the page in the html tag using both
xml:lang attributes; for example:A10
Top of page
7. Code style
7.2 You MUST NOT deliver presentation with tables UNLESS the data is tabular.A12
7.3 You MUST comply with the Semantic Mark-up Standard.
7.4 You MUST NOT use
<base> without specifying the full document path.A13
7.5 Code which is produced and maintained by content production systems SHOULD be as compact and comment-free as possible, to minimise file size and download times (see the Download Standards).
7.6 If this is done, a readable version of the pre-published code SHOULD be available for maintenance purposes.
7.7 Code which is manually produced and maintained SHOULD be well laid out to ensure readability. Reasonable use of blank lines, indenting and comments to denote different sections of the page is encouraged. However, their use SHOULD be balanced with file size considerations.
7.8 You MUST NOT have any comments in your code which include more than two concurrent 'x' characters.A14
7.9 For internal systems you SHOULD highlight the location of support documentation.
Top of page
8.1 All images used in
<img> tags MUST be in either GIF, JPEG or PNG format.
8.2 If you are using PNG files they MUST degrade gracefully, in line with the Browser Support Standards, and still allow for the core content of the site to be conveyed.A15
8.3 You SHOULD be cautious particularly when using PNG files with alpha transparency.A16
8.4 When using an
img tag you MUST specify the height and width attributes.A17
8.5 You MUST NOT use height and width attributes to rescale images to provide thumbnail versions of the full image. Instead you MUST use a separate, resized image file.A18
8.6 Alternative text MUST be supplied as defined in the Textual Equivalents Standards.
8.8 You MUST NOT use transparent spacer GIFs for layout purposes.A20
Top of page
9.1 BBC Online sites MAY use a pop-up window to present content such as media players.A21
9.2 Pop-ups MUST only open when a user has clicked a hypertext link. Pop-ups MUST NOT open unannounced without being a direct result of user input, e.g. automatically on page load.A22
9.3 You MUST clearly label links which launch pop-ups so that users know they are launching a pop-up.
9.4 You MUST NOT allow multiple pop-up windows to open from a single click.
9.5 You MUST give the pop-up focus when it launches. This MUST be specified in the code that launches the pop-up (not in an onload in the pop-up).A23
9.6 Pop-up windows SHOULD NOT have an initial size of more than 760 × 560 pixels, and MUST NOT have an initial size of more than 900 × 680 pixels.A24
9.7 Above 760 × 560 pixels, windows MUST NOT disable scrollbars.A25
9.8 Pop-up windows MUST be resizable by the user.A26
9.10 If the contents of a pop-up are to be excluded from search results you SHOULD use the following tag:
<meta name="robots" content="noindex,nofollow">
9.11 If you want your pop-up to be searchable, you MUST ensure the content is 'standalone' (i.e. it does not require instructions or context found on the page from which the pop-up is opened) and you MUST include a 'Go back to associated bbc.co.uk page' (or similar) link outside the viewable area of the pop-up.
Top of page
10.1 Wherever possible, use the common BBC scripts that are provided for common tasks such as rollovers, plug-in detection, etc. For example, please see the Glow, EMP Frameworks and Developer sites.
Top of page
Appendix A: Why
- A1. Variation of DTDs can have unintended consequences for pan site systems like barlesque which only work based on assumptions of continuity. Also we specify these doctypes to ensure that browsers are in strict mode rather than in quirks mode. This makes a difference in the ruleset that CSS follows, as well as other things.
Strict mode also rules out other aspects that are permitted in other DTDs, e.g. use of target to open new browser windows from a page. XHTML is also a strict set that requires neatness of code, something we want for maintainability and readability purposes. Other DTDs allow messier code that can cause CSS layout issues. This can also aide in collaboration with the server side team where well formed code is easier to be interpreted or output.
- A2. These doctypes are a discrete ruleset which allows us to validate automatically against them, rather than webmasters having to individually check a huge set of requirements.
- A3.For some browsers, for example some versions of IE, if the DTD is not the first line this can stop the browser going into standards mode and break some of the CSS assumptions made in the page, resulting in a broken looking page.
- A4. Although this is more correct for XML validation, its not required for XHTML 1.0 strict and if included can stop the browser going into standards mode and break some of the CSS assumptions made in the page, resulting in a broken looking page.
- A5. This specifies the namespace to be used in the page so that people don't start using their own namespaces, which can cause browser compatibility issues.
sIFR embeds a font in a Flash element that displays the text, preempting the need for a font to have been manually pre-installed on a user's system. Due to potential font licensing issues it is recommended that you use free fonts when creating sIFRs.
- A8. Barlesque specifies a character set. Where pages builders have put in another this has caused odd effects, e.g. the page loading twice, and where the two are different other conflicts have occured on the page.
- A9. This is already done for you when using Barlesque. There are other less reliable methods, which can cause rendering errors.
- A10. This tells systems that may read the page the language of the page. Among other things it tells screen readers what language to read the page in.
- A11. This is a principle of good web page delivery with extensive benefits including improved maintainablity and ease of use for multiple team members working on the same code.
- A12. Tables have semantic meaning, using them for non semantic purposes can confuse screen reader users and lead to a poor experience. Tables cause content to not be separated from presentation, as above. Layouts built using tables are less flexible, render slower and cause a heavier codebase.
- A13. This is to avoid breaking in-page anchors.
- A14. Applications that restrict content containing 3 concurrent 'x' characters may believe your page contains adult content, and deny access accordingly.
- A15. PNGs have different levels of support in our supported browsers. We need to ensure that users are delivered any image that is core content correctly, alt tags are often not displayed with a 'failed' png.
- A16. Known issues at present include, but are not limited to, transparency with IE6.
- A17. This improves the rendering speed of a page, it allows the layout of the page to be understood by the browser as the HTML code is downloaded rather than waiting for the images to download. If this is not supplied the layout of the page can visually jump around as the images are loaded and their visual dimensions discovered.
- A18. Browsers are not good at resizing images on the fly, leading to poorly displayed images. This is also a waste of bandwidth. Upscaling an image leads to poor quality images also.
alt attributes making such images inaccessible.
- A20. The advent of CSS makes this pointless and wasteful of bandwidth and its also against the principles of separating style and content.
- A21. Pop ups are generally recognised as poor for accessibility and usability. There are some cases where you do want to use them however, to maintain a separate viewing experience from the main viewing window.
- A22. This a usability issue, users don't like this happening. User testing has shown that people close them before the load assuming they are adverts.
It also is a problem for screen reader users and people with cognitive disabilities. This is to do with a new browsing experience taking focus, or potentially not taking focus. These also get blocked by pop-up blockers in most browsers.
Pop-ups opening on mouseover is a problem for screen reader users and people with cognitive disabilities, it also annoys users.
- A23 This is to ensure that the pop-up does not appear behind the current browser window. Also pop-up blockers often stop browsers focusing themselves so this needs to be done from the parent window.
- A24. The minimum screen size we support is 800 × 600 which is still commonplace for many devices (monitors and mobile devices). This requirement ensures that the pop-up window does not obscure the clickable area of the main browser window.
- A25. This is ensure that users with 800 × 600 screens whose popups will open at about 760 wide max can still get to all the content.
- A26. This allows users who have enlarged text on the page or are using page zoom to see all the content.
Top of page