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:

Back to page contents

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)

Back to page contents

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

Chrome

Safari

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 contents

Which browser / tool should you use?

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.

Back to page contents

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:

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:

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:

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:

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.

  1. Read the accessibility acceptance criteria. If the accessibility acceptance criteria is missing, ask your team for the criteria before continuing.
  2. 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