User Bar First

This is a debugging block

User Bar Second

This is a debugging block


This is a debugging block

Header Second

This is a debugging block

Carousel Holder

This is a debugging block

Preface First

This is a debugging block

Preface Second

This is a debugging block

Preface Third

This is a debugging block

Header First

This is a debugging block


This is a debugging block

Known issues with website accessibility

Summary of known issues

Our accessibility statement can be read on our Accessibility page.

This page highlights known issues. From a selection of pages from the current site, tested using SortSite and Wave, a number of things require fixing for better accessibility. 

There are a number of minor problems that, as part of the template, affect most pages. To be fixed on the template or as part of a move towards a new content management system will are in the process of fixing the following: 

  • Fix markup errors, causing screen readers to miss content
  • Remove meta viewport tag to disable zoom
  • Correct use of heading elements (h1, h2, h3)
  • Headings for page sections
  • Linked image missing alternative text
  • Redundant alternative text
  • Missing first level heading 

To be fixed via CSS and/or as part of a move towards a new content management system: 

  • Contrast Errors
  • Clearer typography

To be fixed as content creation issues, retrospectively and with training for content creators going forward: 

  • Alt tags on images
  • Correct use of heading elements (h1, h2, h3)
  • Better understanding of structure for content creators

Further detail is available to download in this report

Issues with interactive tools and transactions

Yourburnley forms

On forms are built and hosted through third party software from Granicus (Firmstep) and are ‘skinned’ to look like our website. As a result there is only a certain amount of the functionality that we have control over, the rest will be down to our software supplier to improve and fix.

Firmstep's products have been developed to meet the UK Government market standards. Forms are AA compliant ref WAI guidelines. The precise level of compliance is dependent on the CSS and branding used to display a form and any javascript/code and HTML elements used locally. However, Citizen facing products are being updated to ensure they meet all required elements of the accessibility directive that require implementation in the EN 301 549 mandate. Further information will be noted in the Release notes as changes are implemented. Granicus provided the following statement on features:

  • Relative positioning of all on-screen items. This enables the text size to be adjusted by the client browser gracefully without clipping. This enables Form Fillers who require large text to see all of the form.
  • The tab sequence is set to enable a logical flow from field to field. This assists Form Fillers who cannot use a pointing device to complete the form easily using only a keyboard.
  • Alternative text is set on every image. This ensures that Form Fillers who are blind or partially sighted will be able to understand the meaning of an image and will be able to complete the form without seeing the image.
  • No inline styles are used. This means that a style sheet applied by a Form Filler's software may be used to override the look of the form and display it in a style accessible to that individual. (e.g. using a particular set of high-contrast colours).
  • Forms incorporate all these elements automatically - no special consideration is required as the form is constructed to build in accessibility features.
  • Forms are tested with current versions of IBM Home Page Reader 3.0 and JAWS 4 to assist blind and partially sighted users. When used in conjunction with JAWS, Forms will output to most popular refreshable Braille displays in computer or Grade 2 Braille.

Citizen's account- revenues and benefits

Our revenues and benefits service uses Northgate Citizen Access. Northgate have a programme of work underway now to test the accessibility of all its Citizen Access products and resolve issues found. Northgate have provided the following statement:

  • Baseline test – each product is being tested to the WCAG 2.1 AA standard, in line with Government Digital Service (GDS) advice. Testing is concentrated on the key customer journeys and the highest use pages.
  • This baseline gives us a reference point when we re-test the website in future and we can continue to improve accessibility over time.
  • Resolving accessibility issues – our development teams are already working on the issues identified so far. These changes will be included in the usual scheduled software releases.
  • Achieving full compliance – our aim is to be fully WCAG 2.1 AA compliant by September and we are currently on target to meet that.
  • With the ongoing COVID 19 related uncertainty it makes sense to have a backup plan: any AA failures that aren’t resolved by September will be included in the accessibility statement and then fixed as soon as possible. We are working on the issues raised in priority order to ensure that we resolve the most important issues first.
  • Accessibility statement – we will provide a draft version for each online service that you can choose to use as the basis for your statement, if you wish. The statement is based on the model version from GOV.UK and we’ll complete as much of it as we can, such as: the level of compliance, inaccessible content (if any), the test date and approach, and the legally required information about enforcement and reporting problems.
  • We will also provide functionality to enable you to maintain your accessibility statement, so that you can update it in line with your LA’s policies and local procedures, and deploy it to the website.

Public accessing- planning and development control

Our development control service uses Idox Public Access. Public Access has been built using best practices and standards as defined by WCAG 2.1 and conforms to, at least, the relevant success criteria of WCAG 2.1 level AA.

Here is a short list of some of the accessible features presented by Public Access: 

  • Clear page titles for better orientation. 
  • Alternative text detail for images (“alt text”) and other non-text elements. • Consistent and clear use of headings including a semantic hierarchy (as far as possible). • Association of form controls with labels. 
  • Clear form error messages in proximity to erroneous form fields. 
  • Association of all data cells in a data table with their headers.
  • Meaningful text for hyperlinks (and a title attribute, where applicable).
  • Forms follow a logical order and can be navigated using a keyboard (e.g. Tab key to move between fields).
  • Sufficient foreground and background colour contrast combinations. • Keyboard navigation for menus and calendar controls.

Jobs go Public

Our vacancies are advertised on Jobs Go Public (JGP). JGP have reported:

At JGP, we make sure that our websites are fully accessible and WCAG 2.1 compliant by ensuring that our web developers and designers conduct a thorough audit of every website before it is published. Throughout the design process, we focus on the four principles outlined by WCAG 2.1, ensuring our websites are accessible to people with vision, hearing, mobility and thinking/understanding impairments:0

Perceivable – we make sure all users are able to access and recognise all elements of a website by ensuring that non-text content has a suitable ‘alt text’, screen readers can navigate and read the pages, all text colours and sizes on the page are clear and usable, and that all features are marked up correctly. 

Operable – we make sure that the content on the website is usable, no matter how the user chooses to access it. This includes making sure the website can be operated only using a keyboard, flashing content can be disabled, using meaningful headings and descriptions and ensuring voice commands are easy to use on each page. 

Understandable – we make sure that the content on the website is clear and understandable by designing the website in a consistent, recognisable and clear while ensuring that any content we provide is easy to read and written coherently in plain English. 

Robust – we ensure our website can be interpreted reliably by a wide variety of user agents, including outdated, current and anticipated browsers and assistive technologies by checking they work on a range of devices, using valid HTML, making sure your code lets assistive technologies know what every user interface component is for, and ensuring important messages or modal dialogs are marked up effectively.

Miscelleaneous online payments

Some payment transactions are made through Civica’s eStore product on; the site is not compliant. The cost to replace the eStore with the latest compliant version places a disproportionate financial burden on the authority given the number of transactions that go through the system currently. We are in the process of moving these transactions into our CRM forms- provided by Granicus. 

Sidebar First

This is a debugging block

Postscript First

This is a debugging block

Postscript Second

This is a debugging block


Postscript Third

This is a debugging block

Postscript Fourth

This is a debugging block