Buckinghamshire Fire & Rescue Service underwent an accessibility audit for bucksfire.gov.uk by the Government Digital Service.
The majority of the issues flagged for attention were addressed and marked as fixed by our development company, Weaving Webs, on 16 September 2024.
The issues from the accessibility audit were then re-checked by the Government Digital Service. Issues identified in the retest have been added to this page, which forms a ‘roadmap’ of fixes being carried out, with expected completion dates provided.
Users should be able to use a keyboard to access all content and functionality of a web page. This means the page can be used by people with no vision as well as people who use alternative keyboards or input devices that act as a keyboard.
Sitewide – At 200 per cent zoom and more, the hamburger menu cannot be easily accessed using the keyboard due to accessibility adjustments automatically being selected for keyboard users
Working to resolve with third party provider – expect to be completed by 31 October 2024.
We are aware that at 200 per cent zoom and higher, the hamburger menu on our website may be difficult to access using the keyboard due to automatic accessibility adjustments made for keyboard users. This issue is specifically encountered when using our accessible integration, AccessiBee, which provides many other valuable benefits.
Although the menu appears but does not persist when selected using the keyboard, we have reported this issue to AccessiBee and are working with them to resolve it. We expect a solution to be implemented by 31 October 2024.
Fixed
To address this issue, our web development team implemented a new approach to navigation for mobile breakpoints and zoomed-in views (200% or higher). Instead of a dropdown menu, we have introduced an off-canvas menu. This solution:
This new navigation design resolves the original issue and improves overall usability.
A visible focus helps users know which element has keyboard focus and where they are on the page.
When an element gets focus there should be a visible border around it. Highlighting the element that has keyboard focus or is hovered over can provide information like whether the element is interactive or the scope of that element.
Operating systems have a native indication of focus, which is available in many browsers. The default display of the focus indicator is not always highly visible and may even be difficult to see especially on coloured backgrounds.
Header (on all pages) – The “Call 999” red rectangle is a heading, not a click target. No action needed.
Fixed
The “Call 999” red rectangle is a heading, not a click target. No action needed.
Visual text, including text-based controls can be scaled so that they can be read directly by users with visual impairments without using assistive technology such as a screen magnifier.
Text must be able to be resized up to 200 per cent without loss of content or function.
Sitewide – When tabbing on the page, the accessibility toolbar automatically turns on ‘Keyboard navigation and Blind users’. This results in a pop up appearing with the text ‘Popup panel. Press ESCAPE to close, navigate with TAB’ and this covers content at 200 per cent zoom such as items in the hamburger menu, making it difficult for people to use a keyboard at this zoom level.
Fixed
Popup removed.
Reflow or ‘responsive web design’ helps users with low vision who may need to enlarge text on a webpage and read it in a single column without scrolling in more than one direction. It also helps users who are viewing the page on a mobile device.
If a page does not support reflow it can appear smaller and more difficult to use or content may be cut off.
Navigation menus often collapse into fewer items or into a single menu button to take up less space. All content and functionality must still be fully available.
Sitewide – When tabbing on the page, the accessibility toolbar automatically turns on ‘Keyboard navigation and Blind users’. This results in a pop up appearing with the text ‘Popup panel. Press ESCAPE to close, navigate with TAB’ and this does not reflow to fit the webpage at 400 per cent zoom.
Fixed
Popup removed.
Content that moves, flashes or updates automatically can be a severe distraction for certain users, making it difficult to use the page. It can also cause problems for assistive technologies like screen readers.
For any moving, flashing or scrolling information that:
there should be a way for the user to pause, stop or hide it, unless it is part of an essential activity.
There must be a method to allow the user to pause, stop, hide or control the frequency for content that automatically begins ‘auto-updating’ in parallel with
other content unless it is essential to an activity.
Sitewide – When tabbing on the page, the accessibility toolbar automatically turns on ‘Keyboard navigation and Blind users’. This results in a pop up appearing with the text ‘Popup panel. Press ESCAPE to close, navigate with TAB’ as users navigate the page which counts down, it cannot be paused, stopped, or hidden
There is no way to pause the slider of logos at the bottom of the webpage
Fixed
Popup removed.
Content that appears when an element gets keyboard focus or on mouse pointer hover can confuse users as they may not have intended to trigger an action or may not notice that new content has appeared. This functionality may not show on
mobile devices.
If using this functionality to display extra content, the following must be true:
When hovering over the navigation bar dropdown menus along the top of the webpage, there is no mechanism to dismiss the additional content triggered without moving pointer hover or keyboard focus.
Fixed
Desktop navigation menu updated to allow for dropdowns to be closed on mouse click – users can now dismiss the dropdown content without changing hover or focus. This applies site wide.
Elements must have sufficient colour contrast.
Poor colour contrast makes it difficult for someone with sight loss to see the content properly. If there is a big difference between the background and foreground colours it should be much easier to see the difference between them.
Links along the top of the webpage do not have sufficient colour contrast when they receive focus. This includes ‘Safety advice hub’, ‘About us’ and ‘News’
All content within the section ‘Get a home safety check’ does not have sufficient colour contrast
Links for ‘Privacy’, ‘Cookies’ and ‘Accessibility’ in the footer do not have sufficient colour contrast
All links within the footer do not have sufficient colour contrast when they receive focus. This refers to links under ‘Quick Links’, ‘Safety Advice’, ‘About’ and ‘Services’
All text for ‘Serving you’ and ‘Blogs’ for articles under ‘Latest News and Updates’ do not have sufficient colour contrast
Fixed
Changed navigation focus and active to white underlined. – Changed the colour of contact details and social icons to white. – Changed colour of fifth box in first grid of calls to action from gold to dark blue.
This applies site wide.
Links must have discernible text. Issue found using Deque Axe. All link names should be accessible by a screen reader and be descriptive enough to tell a user where that link will take them.
Common issues include:
All links should receive focus and link text
should not be hidden as this will stop a screen reader from relaying the link information
This refers to the logo at the top of the webpage.
Working to resolve
Seeking more clarification on this issue. Deadline to fix 1 January 2025.
Fixed.
Information in tables must be shown in a way that maintains the relationships between the data even when a user cannot see the table. Assistive technologies like screen readers rely on correct markup within a table to understand and show the correct information to a user.
Tables in PDF documents should be tagged to give information such as row and column titles.
Buckinghamshire and Milton Keynes Fire Authority June 2024 – There are tables in the document that do not have correctly marked up headers. You should review the tags across the document.
Working to deliver a new HTML solution.
Following an accessibility check of the document referenced in the audited, it has been identified that the volume and complexity of the errors found were such that it is not feasible for us to amend them retrospectively within a reasonable timeframe.
We are making reference to this in our accessibility statement.
We are aware that most older PDF documents are not fully accessible to screen reader software. Due to the volume and complexity of these documents, we are currently unable to identify the specific WCAG errors each PDF may have.
Our sample review revealed erratic errors and a large volume of issues. To address this, we are working on a new HTML solution. This will provide a more accessible alternative to PDFs in future content and ensure that new content meets accessibility requirements. We expect to have this solution implemented by 1 January 2025.
Not fixed
Update on PDF Accessibility
We have carefully assessed the resources required to make all existing PDFs accessible or to produce fully accessible HTML alternatives for all content. Due to the significant volume of documents and our current technical capacity, we have determined that addressing all PDFs would constitute a disproportionate burden under the accessibility regulations.
However, we remain committed to improving accessibility in the following ways:
Essential Documents:
Future Commitment:
Improving Author Practices:
Governance Document Templates:
These actions reflect our ongoing efforts to balance practical limitations with our commitment to accessibility for all users.
People with sight loss may not see an image clearly on a page. You need to use a text alternative to share the information. The alternative text must describe the information or function represented by the image.
Screen readers can share the alternative text with the user. In PDF documents you must ensure that images are tagged correctly with alternative text.
Buckinghamshire and Milton Keynes Fire Authority June 2024 – The document has elements that do not have alternative text
Working to deliver a new HTML solution
Following an accessibility check of the document referenced in the audited, it has been identified that the volume and complexity of the errors found were such that it is not feasible for us to amend them retrospectively within a reasonable timeframe.
We are making reference to this in our accessibility statement.
We are aware that most older PDF documents are not fully accessible to screen reader software. Due to the volume and complexity of these documents, we are currently unable to identify the specific WCAG errors each PDF may have.
Our sample review revealed erratic errors and a large volume of issues. To address this, we are working on a new HTML solution. This will provide a more accessible alternative to PDFs in future content and ensure that new content meets accessibility requirements. We expect to have this solution implemented by 1 January 2025.
Not fixed.
Update on PDF Accessibility
We have carefully assessed the resources required to make all existing PDFs accessible or to produce fully accessible HTML alternatives for all content. Due to the significant volume of documents and our current technical capacity, we have determined that addressing all PDFs would constitute a disproportionate burden under the accessibility regulations.
However, we remain committed to improving accessibility in the following ways:
Essential Documents:
Future Commitment:
Improving Author Practices:
Governance Document Templates:
These actions reflect our ongoing efforts to balance practical limitations with our commitment to accessibility for all users.
<li> elements must be contained in a <ul> or <ol>. Issue found using Deque Axe.
Screen readers tell users if a list is present and how many items are in the list. This helps users to know what they are reading and what to expect. It is important to use the correct semantic hierarchy for lists.
Ordered, unordered and description lists must contain semantically correct parent and child elements. When lists contain other elements or they are ordered
incorrectly, screen readers are not able to read the lists accurately.
This refers to the bullet points under ‘How accessible this website is’
Fixed
“<li> elements must be contained in a <ul> or <ol>.” This bullet list is contained within <ul> tags.
Links must be distinguishable without relying on colour. Issue found using Deque Axe.
Links must be distinguished from surrounding text in a way that does not rely on colour.
Colour should not be the only way of visually identifying links on the page. Users with sight loss or problems perceiving colour may not be able to identify the difference in colour between a link and the rest of the content. You should ensure that all links on a page are identifiable by at least one additional method other than colour.
Sitewide – This refers to all links within the content under ‘Accessibility statement for bucksfire.gov.uk‘
Fixed
Added an underline to hyperlinks across the website.
Checklist – Updated 02 October 2024 (following 12-week retest)
Users should be able to use a keyboard to access all content and functionality of a web page. This means the page can be used by people with no vision as well as people who use alternative keyboards or input devices that act as a keyboard.
Sitewide – This is still an issue. The WCAG title needs to be specified in the statement. Can you advise the date you expect it to be fixed by?
WCAG title (WCAG 2.1.1 Keyboard) added to the statement.
We are working to resolve this issue with our third party provider – we expect this to be completed by 31 October 2024.
Conversations are still taking place with Accessibe to come to a resolution on this issue.
Fixed
To address this issue, our web development team implemented a new approach to navigation for mobile breakpoints and zoomed-in views (200% or higher). Instead of a dropdown menu, we have introduced an off-canvas menu. This solution:
This new navigation design resolves the original issue and improves overall usability.
A visible focus helps users know which element has keyboard focus and where they are on the page.
When an element gets focus there should be a visible border around it. Highlighting the element that has keyboard focus or is hovered over can provide information like whether the element is interactive or the scope of that element.
Operating systems have a native indication of focus, which is available in many browsers. The default display of the focus indicator is not always highly visible and may even be difficult to see especially on coloured backgrounds.
The keyboard focus is still missing when tabbing between ‘Search’ and ‘Find out more’, and ‘Search’ and ‘View Vacancies’, and ‘Search’ and ‘Get Started’, AND ‘Search’ and ‘Bucksfire.gov’ (apologies, not Call 999).
Fixed.
Keyboard focus now tabs between the search input field to the search button and then the next focussable object in the page.
Content that appears when an element gets keyboard focus or on mouse pointer hover can confuse users as they may not have intended to trigger an action or may not notice that new content has appeared. This functionality may not show on mobile devices.
If using this functionality to display extra content, the following must be true:
This is still an issue (navigation bar dropdown menus along the top of the webpage) as it cannot be dismissed using the keyboard.
No action taken, at this point as we are unclear on the issue. A request has been raised with GDS to provide a specific example of this problem, and explain how this is not satisfying 1.4.13 (outlined below).
WCAG 1.4.13 states:
“If using this functionality to display extra content, the following must be true: There should be a way of dismissing the content without changing the hover or focus – unless the content communicates an input error or does not obscure or replace other content”. Based on this wording we believe this statement to be satisfied.
“If using keyboard the dropdowns can be dismissed with ESC key, if hovering with mouse the dropdowns can be dismissed by clicking on the heading.” Based on this wording we believe this statement to be satisfied.
“If content is triggered on pointer hover, the pointer must be able to be moved over the content without disappearing.” Based on this wording we believe this statement to be satisfied.
“The content must remain visible until the hover or focus is removed, the user dismisses it, or the information is no longer valid.” Based on this wording we believe this statement to be satisfied.
Fixed
Our web development team has addressed this by rebuilding the mobile breakpoint menus. As a result:
This update resolves the identified issue and improves site usability.
Issue and description:
Elements must have sufficient colour contrast.
Poor colour contrast makes it difficult for someone with sight loss to see the content properly. If there is a big difference between the background and foreground colours it should be much easier to see the difference between them.
Links for ‘Privacy’, ‘Cookies’ and ‘Accessibility’ in the footer do not have sufficient colour contrast. This is still an issue when the mouse hovers over ‘Accessibility’ All text for ‘Serving you’ and ‘Blogs’ for articles under ‘Latest News and Updates’ do not have sufficient colour contrast. This is still an issue.
No action taken.
Privacy, Cookies, and Accessibility appear to have acceptable colour contrast on mouseover. Colour contrast displays as 4.64. As far as we can tell the requirement for 2.2 AA is colour contrast of 4.5:1.
Colour contrast improved under “Latest news and updates”.
Information in tables must be shown in a way that maintains the relationships between the data even when a user cannot see the table. Assistive technologies like screen readers rely on correct markup within a table to understand and show the correct information to a user.
Tables in PDF documents should be tagged to give information such as row and column titles.
Buckinghamshire and Milton Keynes Fire Authority June 2024 – There are tables in the document that do not have correctly marked up headers. You should review the tags across the document.
This is still an issue at 12-week retest. Please provide the plan and timeline to fix this. The WCAG issue should be listed in your statement.
Working to deliver a new HTML solution.
WCAG title (WCAG 1.3.1 Info and Relationships: Tables) added to the statement.
Following an accessibility check of the document referenced in the audit, it has been identified that the volume and complexity of the errors found were such that it is not feasible for us to amend them retrospectively within a reasonable timeframe.
We are making reference to this in our accessibility statement.
We are aware that most older PDF documents are not fully accessible to screen reader software. Due to the volume and complexity of these documents, we are currently unable to identify the specific WCAG errors each PDF may have.
Our sample review revealed erratic errors and a large volume of issues, to address this, we are working on a new HTML solution. This will provide a more accessible alternative to PDFs in future content and ensure that new content meets accessibility requirements. We expect to have this solution implemented by 1 January 2025.
Not fixed
Update on PDF Accessibility
We have carefully assessed the resources required to make all existing PDFs accessible or to produce fully accessible HTML alternatives for all content. Due to the significant volume of documents and our current technical capacity, we have determined that addressing all PDFs would constitute a disproportionate burden under the accessibility regulations.
However, we remain committed to improving accessibility in the following ways:
Essential Documents:
Future Commitment:
Improving Author Practices:
Governance Document Templates:
These actions reflect our ongoing efforts to balance practical limitations with our commitment to accessibility for all users.
People with sight loss may not see an image clearly on a page. You need to use a text alternative to share the information. The alternative text must describe the information or function represented by the image.
Screen readers can share the alternative text with the user. In PDF documents you must ensure that images are tagged correctly with alternative text.
Buckinghamshire and Milton Keynes Fire Authority June 2024 – The document has elements that do not have alternative text.
This is still an issue. Please provide the plan and timeline to fix this. The WCAG issue should be listed in your statement.
Working to deliver a new HTML solution.
Status as of 5 December 2024:
Not Fixed
Comments:
WAG title (WCAG 1.1.1 Non-text content) added to the statement.
Following an accessibility check of the document referenced in the audit, it has been identified that the volume and complexity of the errors found were such that it is not feasible for us to amend them retrospectively within a reasonable timeframe.
We are making reference to this in our accessibility statement.
We are aware that most older PDF documents are not fully accessible to screen reader software. Due to the volume and complexity of these documents, we are currently unable to identify the specific WCAG errors each PDF may have.
Our sample review revealed erratic errors and a large volume of issues. To address this, we are working on a new HTML solution. This will provide a more accessible alternative to PDFs in future content and ensure that new content meets accessibility requirements. We expect to have this solution implemented by 1 January 2025.
