Testing steps, No CSS
Semantic HTML is the foundation of accessible user experience on the web. When HTML is viewed in the browser without styling, this is the ‘no CSS’ experience, and this can be presented to users at times; in which case core content should be accessible and readable.
We’ll take you step by step through how to test a component or feature with no CSS, using a browser setting or third party tool.
Why no CSS?
Viewing the ‘no CSS’ experience is one of the practices that helps us meet the BBC Mobile Accessibility Guidelines and recommendations in the BBC Guide to Accessible HTML Documents, specifically:
Don’t leave it to chance:
- Technology - The no CSS experience provides a baseline core experience, dependent on minimum technology. By it’s nature this offers multiple ways for users to consume content. It allows users to choose software and use devices that work best for them, in a broad range of situations and circumstances.
- Foundation - The no CSS experience is the foundation upon which accessible user experiences are enhanced (with CSS and JavaScript).
- Suporting users - A good no CSS user experience supports users who change styling settings (to adapt the appearance of pages). For example by using a custom style sheet, to suit specific user needs for reading content and using web pages.
- Chance - A no CSS experience gives our content more chance of being consumed. For example if viewing on an older device or browser, with limited support, robust content that minimises dependencies is more likely to succeed. "The minimum dependency for a web site should be an internet connection and the ability to parse HTML." (Progressive enhancement guide)
- Access - No CSS might not always be the users choice. When it isn’t we want to give users the best chance of accessing news, and for the experience to be as good as it can be. For example, in disaster scenarios, when data maybe scace, it’s imperative to be able to access news if needed.
What is core content?
Core content are the elements that fulfill the core purpose of a page. For example, the core content of a news article page, are the elements that form the story itself. The onwards jouneys on a news article page are not core content, though the accessibility of non-core page elements still matters.
Other examples of core content
Live pages - A ‘Live’ page has a core purpose to provide the newest information about an event to the users. The core content includes the newest information at the time of a page request. The experience is enhanced when JavaScript automatically updates this content without a user having to take action. (Progressive enhancement guide)
Media pages - If the primary content of a page is dynamic with additional dependencies, such as a video or game, then the core purpose could be to provide a context from which to launch that content... This might include information on the technology dependency required and links to alternative content. (Progressive enhancement guide)
How to turn CSS off
Some browsers have built in settings which enable you to easily turn off / disable CSS. With browsers that don’t offer these settings, you can use a third party tool.
Firefox
- Built in setting: Go to the toolbar and choose: 'View', then 'Page Style', then 'No Style'.
- Third party tool: Open Web Developer browser extension and choose: 'CSS', then 'Disable All Styles'. Note, this tool does not disable styles in shadow DOM content.
Chrome
- Third party tool: Open Web Developer browser extension and choose: 'CSS', then 'Disable All Styles'. Note, this tool does not disable styles in shadow DOM content.
Safari
- Built in setting: Go to the toolbar, if you don't see 'Develop', go to 'Settings' in the 'Safari' menu, then 'Advanced', then check 'Show features for web developers'. You should now see 'Develop' in the toolbar, from here choose 'Show Web Inspector'. Within the Web Inspector toolbar choose: 'Device Settings', then 'Core Features', then 'Disable CSS'.
Note, this guide takes one approach, there are other ways you could do this, such as by directly removing CSS via a web inspector browser tool.
Back to page contentsWhich browser / tool should you use?
- Product - Take into account your product browser stats, and also no css and accessiblity features offered by a browser. For example, your product may have the most users in one browser, if that browser has no or limited, no css and accessibility features built in, you may wish to also check no css in a browser that offers wider built in no css and accessiblity settings to users.
- The code - Also, take into account the way the page you are viewing is constructed in the DOM, for example if it contains shadow DOM content.
- Browser setting - If a built a browser setting is available, use this over a third party tool.
Shadow DOM content
Shadow DOM content is encapsulated, this means it contains it’s own CSS seperate from the main page. CSS for this type of content may not ‘turn off’ with all browser settings / tools. This could be dependent on a number of factors, for example, the way the browser / tool was designed, page load speeds or component loading methods; such as if the component is loaded by a user action.
Encapsulated content is typically content that remains meaningful when separated from the main content, perphas of a more complex nature, supplied by a different team or third party, such as a media player, map or graphical visualisation.
Testing steps
We’ll take you step by step through how to test a component or feature. Following the same steps every time, ensures that everyone is testing using the same methods and using the most common techniques. The steps also enable anyone, in any role, to test a component or feature with no CSS, for the first time.
As you go, make notes of any bugs you find.
Step 1 - Open browser
Consider which browser to use, then open the browser.
Step 2 - Go to the testing url
Navigate to or type in the testing url.
Step 3 - Turn off CSS
Consider which method to use to turn CSS off, then turn off CSS.
Step 4 - Accessible
View the component and check content is accessible and readable. In particular, check the following:
- Semantic HTML - Is heirachy and meaning provided by semantic HTML? For example, do headings have a bold weight and a text size bigger than that of surronding text, does list content have bullet points?
- Links - Do links have an affordance that provides a visual clue for sighted users that they are actionable, do they look like links?
- Buttons - Do buttons look like buttons?
- SVGs - Check icons / graphics / logos that are displayed as white when the user has CSS, can be seen when there is no CSS. For example, the BBC logo is white in colour when the user has CSS, when there is no CSS, web pages have a white background, the logo wouldn’t be perceivable. Inorder for the logo to be seen on a white background when there is no CSS, it needs to use a perceivable colour, such as black. This is especially important for icons that provide meaning. Note, colours cannot be changed with some image formats, such as jpeg, png or gif, use SVGs if possible. Also note that this maybe more difficut to acheive if SVG’s use more than one colour.
Bug examples
- Content has no heirachy or meaning.
- Links have the affordance of a button.
- Buttons have the affordance of a link.
- Core white icons or graphics can’t be perceived. For example, a white BBC logo can’t be perceived on a white page background. Note, for SVGs with more than one colour, only some customisation maybe possible.
Step 5 - Readable
View the component and check content is accessible and readable. In particular, check the following:
- Reading experience - Is the reading experience is as good as it can be?
- Spaces - Are there spaces between all words?
- Formatting - Are words formatted correctly, do use they corrrect capatilastion and grammer?
Bug examples
- Words have no seperation between them
- Words aren’t formatted correctly, they use incorrrect capatilastion or grammer.
Step 6 - Core content
View the component and check content is accessible and readable. In particular, check the following:
- Missing - Are elements or features missing? If so, is the core purpose of the component or feature still fullfilled?
- Not equivalent - If the component or features aren’t equivalent to that viewed with CSS, does the component or feature still make sense?
- Functional - Is the component or feature still functional / useable?
Bug examples
- Core purpose isn’t fullfilled as core content is missing
- The feature or component doesn’t make sense
Step 7 - UX
View the component and check content is accessible and readable. In particular, check the following:
- Sized in proportion - The user experience is enhanced, and components are more usable, when non-text content (such as icons, graphics, images etc) is sized in proportion with text content.
- Perfect - It’s ok if it’s not perfect, some content maybe repeated (due to the way a component or feature is built). Ask an engineer if you aren’t sure.
Bug examples
- Non-text content is not sized in proportion with text content
Step 8 - Accessibility acceptance criteria
Accessibility acceptance criteria can be used for additional manual testing steps specific to your component and documented UX.
- Read the accessibility acceptance criteria. If the accessibility acceptance criteria is missing, ask your team for the criteria before continuing.
- Check that any criteria that is specific to no CSS is met.
Step 9 - Document any bugs
Document any accessibility bugs found, include as much information as you can, including information on how to replicate the issue and the bug priority level.
Note, this guide takes one approach, there are other ways you could do this. Back to top