Tracking bugs in browsers, assistive technologies and operating systems that have been reported by GDS
Tracking bugs in browsers, assistive technologies and operating systems that have been reported by GDS
Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1560117
Date: 2019-07-19
Reported by: Nick Colley
Related to: alphagov/govuk-frontend#1464
In some circumstances website authors will use aria roles to indicate that a link that looks like a button should be announced as a button.
This is useful so that assistive technologies such as dictation software can access this button, for example "click button".
In Firefox on MacOS these buttons are not part of the tab order by default, which could cause barriers.
Both the button with the markup and the 'link button' with [role=button] should be tabbable
Only the button with
markup is tabbableUpstream bug: https://bugs.webkit.org/show_bug.cgi?id=179012
Date: 2017-10-30
Reported by: Anika Henke
Related to: n/a
When following in-page links, VoiceOver doesn't always read out the next text. This is at least true for paragraphs, inputs and legends. This is not too bad because the text gets read out when swiping further, except for legends. When jumping to a legend and swiping further, the text of the legend is entirely skipped, even when swiping back and forth again. This does not happen when swiping without having followed the link.
It's difficult to tell if this is still true on iOS 11 due to another bug [https://bugs.webkit.org/show_bug.cgi?id=179011].
The text for the legend is not read out.
The legend should be read out, if not directly after following the link, at least after swiping further.
Legends (and fieldsets) are not always just used to group form elements, they can contain information that is vital to understand and complete a form. E.g. with Yes and No questions, you would have Yes and No labels for the radio buttons but the actual question would often be in a legend. It would be impossible for screen reader users to know what the question was if they followed a link to it. And in-page links are typical for pointing users to specific errors after they submitted a form.
Upstream bug: Ref no 170922-000443 (not public!)
Date: 2017-09-20 (?)
Reported by: Anika Henke
Related to: alphagov/govuk-frontend#1101
The bug report can be accessed with the GDS internal "nuance" google group account and can only be seen when you're logged in with that user.
The content of the bug report is:
You can neither select any number fields (i.e. inputs with the type 'number') nor dictate into them with Dragon 13 in IE 11, or latest Chrome or Firefox.
(The selection obviously works with mouse grid, and the input works with the Dictation Box.)
You can try it out in this reduced test case: http://jsbin.com/munuvub
Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1494746
Date: 2018-09-27
Reported by: Anika Henke
Related to: alphagov/govuk-frontend#1032
Words are merged together in screen readers when using word-wrap: break-word with a small width. This also happens when using word-break: break-all or word-wrap: break-word.
Open the reduced test case on http://jsbin.com/guxovas
This test case has (sometimes hidden) content ("Posted on") with a width of 1px inside a container with word-wrap: break-word.
Either navigate with a screen reader (e.g. NVDA) to the content under "Hidden content with the issue" and listen to what it reads.
Or alternatively open the accessibility inspector and read what the "textleaf" reports the content is.
You will hear (or read) "Postedon".
You should hear (or read) "Posted on".
Upstream bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1111398
Date: 2020-07-20
Reported by: @36degrees
Related to: N/A
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36
(1) Open https://jsfiddle.net/36degrees/kqz20pca/2/show (or create an HTML page that includes the HTML included in 'Any other comments?')
(2) Open Developer Tools, and highlight the div with the text 'Hello World' (within the iframe)
(3) Run the command 'Capture node screenshot'
A screenshot of the node with the text 'Hello World' is downloaded.
A screenshot of the parent document, cropped to the same size as the highlighted node (100px x 100px) is downloaded – in this case, a blue square.
Did this work before? N/A
Chrome version: 84.0.4147.89 Channel: n/a
OS Version: OS X 10.14.6
Flash Version:
HTML used in JSFiddle:
<div style="padding: 100px 0; background-color: blue;">
<iframe srcdoc="<div style='width: 100px; height: 100px; background-color: red; color: white;'>Hello World</div>" />
</div>
Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1322692
Date: 2016-12-09
Reported by: Robin Whittleton (@robinwhittleton)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20161208075029
Clicked on an unselected radio button.
Click event fired.
Click and focus events fired.
Chrome fires either a focus or focusin event (depending on delegation) in addition to the click event.
Upstream bug: https://bugs.chromium.org/p/chromium/issues/detail?id=687118
Date: 2017-01-31
Reported by: Oliver Byford
Related to: -
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36
Example URL:
http://codepen.io/36degrees/pen/JEpYrr
Steps to reproduce the problem:
What is the expected behavior?
The new element should appear without affecting the browser's scroll offset.
What went wrong?
The scroll offset is shifted by the height of the introduced element, causing a 'jump' for the end user.
Does it occur on multiple sites: Yes
Is it a problem with a plugin? No
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 56.0.2924.76 Channel: stable
OS Version: OS X 10.11.6
Flash Version: Shockwave Flash 24.0 r0
The linked code pen is a simplified test case based on behaviour seen at http://webarchive.nationalarchives.gov.uk/20161126131022/https://www.gov.uk/service-manual/agile-delivery/agile-government-services-introduction – where the introduction of a 'shim' element when making an element position: fixedcauses a jump in the page.
This behaviour was not seen in Chrome 55.
Upstream bug: https://bugs.chromium.org/p/chromium/issues/detail?id=312882
Date: 2013-10-29
Reported by: [email protected]
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
Depending on where you click the link it will return either:
http://www.dwp.gov.uk/local-authority-staff/housing
or https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/240112/null
Did this work before? N/A
Chrome version: 30.0.1599.101 Channel: stable
OS Version: OS X 10.7.5
Flash Version: Shockwave Flash 11.9 r900
GOV.UK has replaced 24 departmental websites but there are many URLs that continue to link to those old websites. Almost all old URLs have been successfully mapped to a suitable location on GOV.UK.
However, those old URLs live on inside PDFs and often they break across several lines. Where there is a '-' in the middle of a link at the end of a line the PDF viewer is interpreting that as a line break and causing the links to fail.
This is not a problem using Safari or standalone Adobe Reader.
Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=446511#c9
Date: 2015-09-01
Reported by: Robin Whittleton (@robinwhittleton)
[Robin] did some research on how radios and checkboxes resize in various browsers: https://gdstechnology.blog.gov.uk/2015/08/27/making-radio-buttons-and-checkboxes-easier-to-use/
Firefox on Windows is the sole browser on Windows 10 that I tested that still doesn’t let you resize checkboxes/radios. Everyone else either users the vector system widgets (IE, Edge), what appear to be built-in but still vector widgets (Chrome) or if you’re Opera Windows Classic widgets(?!).
It’d be lovely if Firefox could fix this regression. At the moment our alternative is to hand-roll custom radios / checkboxes with all of the difficulty of maintenance that brings.
Firefox on Windows 10: https://gdstechnology.blog.gov.uk/wp-content/uploads/sites/31/2015/08/win_10_firefox.png
IE11 on Windows 10: https://gdstechnology.blog.gov.uk/wp-content/uploads/sites/31/2015/08/win_10_ie11.png
Edge on Windows 10: https://gdstechnology.blog.gov.uk/wp-content/uploads/sites/31/2015/08/win_10_edge.png
Chrome on Windows 10: https://gdstechnology.blog.gov.uk/wp-content/uploads/sites/31/2015/08/win_10_chrome.png
Opera on Windows 10: https://gdstechnology.blog.gov.uk/wp-content/uploads/sites/31/2015/08/win_10_opera.png
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=148676
Date: 2015-09-01
Reported by: Robin Whittleton (@robinwhittleton)
Related to: https://technology.blog.gov.uk/2015/08/27/making-radio-buttons-and-checkboxes-easier-to-use/
Radio buttons on iOS (unlike on OS X) can be resized by styling width and height which is great. There’s a small bug though: the size of the border radius that defines a radio button as a circle appears to be set in pixels. This means that as the height and width of the radio increases they look progressively more square. Can this radius be set at 50% instead of a fixed pixel value?
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=180871
Date: 2017-12-15
Reported by: Anika Henke
Related to: alphagov/govuk_elements#572 (ish)
VoiceOver with Safari on iOS announces the wrong state (collapsed or expanded) when the element was just collapsed. It announces the correct state when swiping forwards and back again.
On step 4 VoiceOver says "Open this, collapsed", although the section is expanded.
VoiceOver should say "Open this, expanded" like it does on step 6, or like it does in macOS on step 4.
Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1335476
Date: 2017-01-31
Reported by: Anika Henke
Related to: alphagov/govuk_elements#397
Inputs are invisible (black on black) when changing colour settings.
The last two examples have completely invisible text as the combination of the styles results in black text on a black background.
Or rather, the text is always black and the background is transparent. And because the overall background is set to black, the transparent input background is black as well.
Either the form elements should follow the user specified colours (yellow text on a black background. Or it should have fixed colours (e.g. black text on a white background).
The latter is how it used to be until Firefox 11 (the bug appeared in Firefox 12).
In any case, the two colours need to be set dependent of each other, either both colours should be flexible or fixed. Whenever a transparent background colour is used, the text colour mustn't be fixed.
I've just rechecked this in Firefox 66 and two of the three invisible cases are now fixed. The only case left which is still producing an invisible input is the last one, i.e. for inputs having both a background colour and a border. The screenshot shows this.
On top of that, I also found that adding -moz-appearance: none or -webkit-appearance: none makes all invisible except the 1st and 4th, i.e. setting any background makes them invisible. Shall I report that as a new bug?
Upstream bug: nvaccess/nvda#10810
Date: 2020-02-21
Reported by: @hannalaakso and @NickColley
Related to: alphagov/govuk-frontend#1696
The hint text for the aria-describedby on the input type="checkbox" supersedes the hint text for the aria-describedby on the fieldset. So the user only gets one hint read to them when they jump to the input through the tab index – the one on the input, rather than the legend.
<fieldset aria-describedby="confirm-nationality-hint">
<legend>
What is your nationality?
</legend>
<span id="confirm-nationality-hint">
Select all options that are relevant to you.
</span>
<br>
<input id="confirm-nationality" name="confirm-nationality" type="checkbox" value="british-nationality" aria-describedby="confirm-nationality-item-hint">
<label for="confirm-nationality">British</label>
<span id="confirm-nationality-item-hint" class="govuk-hint govuk-checkboxes__hint">
including English, Scottish, Welsh and Northern Irish
</span>
<br>
<input name="confirm-nationality" type="checkbox" value="irish-nationality" aria-describedby="confirm-nationality-2-item-hint">
<label class="govuk-label govuk-checkboxes__label" for="confirm-nationality-2">Irish</label>
<span id="confirm-nationality-2-item-hint" class="govuk-hint govuk-checkboxes__hint">
including from Northern Ireland
</span>
<br>
<input id="confirm-nationality-3" name="confirm-nationality" type="checkbox" value="other-country-nationality" data-aria-controls="conditional-confirm-nationality-3">
<label for="confirm-nationality-3">Citizen of a different country</label>
</fieldset>JSBIN: https://output.jsbin.com/juyaquq
NVDA Version: 2019.2.1
Chrome version: 79.0.3945.130
Firefox version: 72.0.2
The legend is announced, followed by the legend hint, then the input and finally the input hint.
The legend is announced, then the input and finally the input hint.
Upstream bug: Ref no 170922-000445 (not public!)
Date: 2017-09-20 (?)
Reported by: Anika Henke
Related to: n/a
The bug report can be accessed with the GDS internal "nuance" google group account and can only be seen when you're logged in with that user.
The content of that is:
You cannot operate the file upload button with Dragon 13 in IE 11 or Chrome.
(It works in Firefox. And it obviously works with mouse grid.)
You can try it out in this reduced test case: http://jsbin.com/dezapiIf you think the bug is in the browser and not in Dragon, please let me know and I'm happy to report it for those browsers as well.
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=173661
Date: 2017-06-21
Reported by: Anika Henke
Related to: n/a
When filling in any form with multiple fields with VoiceOver on iOS, the fields cannot be filled in one by one due to bad virtual focus management, making it highly likely that a couple will be missed.
Alternatively:
5b. Hit the "forward" button
6b. Repeat until the end of the form
In the first scenario some random field will receive the virtual focus, skipping a couple of fields.
In the second scenario the next field will receive the virtual focus, except that radio buttons and checkboxes will be skipped.
In both scenarios the next field (irrespective of type) should receive the focus. Or giving the current field the focus would also make sense.
Screen reader users who cannot see the form have no way of knowing that some fields have been skipped. They cannot rely on standard ways of filling in a form. The only way for them to know is by going through the whole form after filling it in to make sure they haven't missed anything.
It is possible to fill in a form this way, but very, very annoying and much more time-consuming than necessary.
One discussion about this bug can be found here: http://webaim.org/discussion/mail_thread?thread=7141
Someone mentioned on there that they filed a bug report but I searched and couldn't find anything.
As far as I know it happens at least on iOS9 and iOS10.
Upstream bug: nvaccess/nvda#8255
Date: 2018-05-10
Reported by: Oliver Byford
Related to: alphagov/govuk-frontend#681
<form>
<fieldset>
<legend>Have you changed your name?</legend>
<span id="hint">Choose yes or no</span>
<label>
<input type="radio" name="changed-name" value="yes" aria-describedby="hint">Yes
</label>
<label>
<input type="radio" name="changed-name" value="no" aria-describedby="hint">No
</label>
</fieldset>
</form>NVDA should announce "Have you changed your name? Grouping, yes radio button not checked, choose yes or no, 1 of 2."
NVDA announces "Have you changed your name? Grouping, yes radio button not checked, choose yes or number 1 of 2."
NVDA version:
2017.4
NVDA Installed or portable:
Installed
Other information:
N/A
Windows version:
Windows 10 Version 1709 Build 16299.431
Name and version of other software in use when reproducing the issue:
Firefox 52.8.0
Does the issue still occur after restarting your PC?
Yes
Have you tried any other versions of NVDA?
No
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=180865
Date: 2017-12-15
Reported by: Anika Henke
Related to: alphagov/govuk_elements#573
When you access a details element with VoiceOver in iOS 10 or iOS 11, it doesn't announce that it can be expanded when it also has the ARIA role "group".
Although the group role is the default implicit role of the details element [http://w3c.github.io/html/interactive-elements.html#elementdef-details] and it is recommended not to use it in such a case [http://w3c.github.io/html/dom.html#do-not-set], it should also not make the element behave any differently.
VoiceOver says "Open this".
VoiceOver should say "Open this, collapsed" like it does in the second example (which doesn't include the group role).
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=191749#c0
Date: 2018-11-16
Reported by: Oliver Byford
Related to: alphagov/govuk-frontend#1056 (comment)
This may well affect other types of inputs, but more severe bugs affecting text inputs, text areas, radio buttons and checkboxes (191746, 191748) means it's impossible to tell.
Given the following markup:
<a href="#select">Link to select</a><br>
<a href="#file">Link to input type="file"</a>
<br><br>
<label for="select">Label for select</label><br>
<span id="select-description">Description for select</span><br>
<select id="select" name="select" aria-describedby="select-description">
<option value="one" selected>Option one</option>
<option value="two">Option two</option>
<option value="three">Option three</option>
</select>
<br><br>
<label for="file">Label for file upload</label>
<span id="file-description">Description for file upload</span>
<input id="file" name="file" type="file" aria-describedby="file-description">
Focus the link to each input type and activate it by double-tapping.
Voiceover should include the description associated using aria-describedby, as it does when focusing the element by swiping through the document:
"Legend for select, option one, popup button. Description for select. Double-tap to active the picker"
Voiceover does not include the description as part of the announcement, nor the instruction 'Double-tap to activate the picker':
"Legend for select, option one, popup button."
Voiceover should include the description associated using aria-describedby, as it does when focusing the element by swiping through the document:
"Label for file upload, no file selected, button. Description for file upload."
Voiceover does not include the description as part of the announcement, nor the fact that the focussed element is a button:
"Label for file upload, no file selected."
Tested in iOS 12.1 (16B92) on an iPhone X (A1901)
Upstream bug: https://openradar.appspot.com/radar?id=4937966329790464
Date: 2016-12-01
Reported by: Oliver Byford
Related to: -
When an HTML element that was previously of type position: sticky; is changed to type position: fixed; it is rendered incorrectly by Webkit browsers on iOS.
The nav element 'expands' to fill the entire viewport.
The page is rendered incorrectly - the navigation element occupies approximately the lower third of the screen. Despite this, when interacting with the screen, the browser reacts as if the elements are in their correct positions.
Inspecting the page using Safari's remote debugging also highlights the elements as if they are where they 'should be'.
If the same CSS is applied when the page is loaded, the example appears correctly (as in open.html).
iOS 10.1 (14B72), Safari or Chrome 54.0.2840.91
Hosted version of example available at https://36degrees.github.io/webkit-ios-fixed-sticky/
Not able to reproduce on my mac (Safari Version 10.0 (12602.1.50.0.10), Mac OS 10.12 (16A323))
iPhone 6s
Upstream bug: https://bugs.chromium.org/p/chromium/issues/detail?id=527068
Date: 2015-09-01
Reported by: Robin Whittleton (@robinwhittleton)
Steps to reproduce the problem:
What is the expected behavior?
Each radio / checkbox would match its styled size.
What went wrong?
They don’t – they’re all either a ‘small’ style (<14px) or a ‘normal’ style.
Does it occur on multiple sites: Yes
Is it a problem with a plugin? No
Did this work before? No
Does this work in other browsers? No Safari 8, Opera latest, but not Firefox latest
Chrome version: 47.0.2499.0 (64-bit) Channel: n/a
OS Version: OS X 10.10
Flash Version:
I guess this is down to using raster images as the basis for the inputs (same as Safari). I filed the same bug against Webkit at https://bugs.webkit.org/show_bug.cgi?id=148675 . There is one difference though: if you zoom using Cmd + / Cmd - (i.e. specifically not with a trackpad gesture) the browser reverts to its built in and beautifully resizable vector inputs. A trackpad gesture just keeps the OS X style inputs but blurs them as it zooms in.
I’ve got no problem with using OS X style radios / checkboxes by default, but can we change the behaviour such that if you try to set a size for radio / checkbox inputs it uses the built-in vector versions rather than the OS X rasters?
Upstream bug: FreedomScientific/standards-support#117
Date: 2018-09-20
Reported by: Nick Colley
We have had feedback from a JAWs user that extra information regarding the tabs list would be useful: alphagov/govuk-frontend#943
In other popular screen readers when interacting with tabs the user is given a summary of the amount of tabs in the tablist that they can interact with.
For example in VoiceOver: "Past day, selected, tab, 1 of 4 has keyboard focus"
There is a similar announcement for NVDA.
I have looked at https://freedomscientific.github.io/VFO-standards-support/aria.html#index-aria-tablist which seems to suggest that the tablist role has limited support, so for this reason I have marked this a feature request but please feel free to rename this issue if you think otherwise.
A summary of the tabs available to interact with.
Only the first tab is announced
JAWS 2017/2018
Windows 7
Internet Explorer 11
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=198456
Date: 2019-06-01
Reported by: Anika Henke
Related to: ?
When a checkbox is hidden behind another checkbox, it is impossible to tick or untick it with VoiceOver on iOS.
This works correctly with links or with the same checkbox in other screen readers, including VoiceOver on macOS.
The checkbox stays unticked, VoiceOver says "unticked" and the visible checkbox on top of it (labelled "Checkbox inside overlay") gets ticked instead
The checkbox should get ticked, VoiceOver should say "ticked"
Upstream bug: FreedomScientific/standards-support#228
Date: 2019-07-30
Reported by: Nick Colley
Related to: alphagov/govuk-design-system#938
User feedback:
When using JAWS, I navigated with the ‘Tab’ key and located a link which announced as ‘Search design system’. I selected the link and was taken directly to an autocomplete to search for a component.
Video demonstration in context on the Design System website: https://youtu.be/CFvk9W5hE0o
I've managed to reproduce this issue in Internet Explorer 11 and using JAWS 2018, it seems to be a bug with JAWS where the link's announcement is duplicated onto the input's announcement.
Tab to Design System home link
Announcement: "GOV.UK Design System link"
Tab to 'Search design system' input
Announcement: "Search design system visited link"
Shift tab to Design System home link
Announcement: "GOV.UK Design System link"
Tab to 'Search design system' input
Announcement: "Search design system edit combo [...]"
This does not happen when tabbing away from the input and tabbing back towards in the input.
When removing the [role=combobox] wrapper, the problem no longer exists.
Minimal markup to reproduce the issue:
<a href="/">Home</a>
<label for="username">Username</label>
<div role="combobox">
<input id="username">
</div>When tabbing to the input it is announced correctly.
When tabbing to the input it is announced as the previous announcement, in this case it is announced as the previous link.
Upstream bug: N/A (reported via e-mail) As of Dec 2020: FreedomScientific/standards-support#478
Date: 2019-05-30
Reported by: Oliver Byford
Related to: alphagov/govuk-frontend#1396
ZoomText Reader prioritises the name attribute instead of the id attribute when
associating labels with inputs.
As per the HTML specification, the for attribute should reference the label by ID:
https://www.w3.org/TR/html52/sec-forms.html#element-attrdef-label-for
Given the following markup, with:
<fieldset>
<input id="foo" name="foo" type="radio" value="foo">
<label for="foo">
Foo
</label>
<input id="bar" name="foo" type="radio" value="bar">
<label for="bar">
Bar
</label>
</fieldset>
With Reader enabled, with echo turned on for mouse hover, hover over each radio button in turn with ZoomText.
Expected result:
Actual result:
Tested in:
Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1200559
Date: 2015-09-01
Reported by: Robin Whittleton (@robinwhittleton)
In bug 394892 Markus Stange fixed radios and checkboxes to use native Cocoa widgets and made them resizable, which puts Firefox a step up from where Chrome and Safari currently are. It’s a shame though that they look pixellated at large sizes (see attached image).
In the intervening time an @2x set of image states for checkboxes and radios has been introduced (try setting transform:scale(2); against an input in Chrome or Safari) which would be a stop-gap, but it would be very nice if this could be resolution independent.
Other browsers (for example Chrome on Windows) have their own set of vector widgets including checkboxes and radios. Is this something Mozilla would be interested in doing? It would obviously be better if OS X introduced resolution independent controls and I’d imagine it can’t be far off, so that might be the better path.
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=174936
Date: 2017-01-31
Reported by: Anika Henke
Related to: n/a
When a legend is within a main (or header, nav or aside) element, it won't be read out if form items are navigated by the VO+Cmd+J shortcut on macOS. When they are navigated via the rotor 'form controls' navigation on iOS, a legend within a footer or article element won't work either. Of new semantic elements I tried, only section seems to be fine in both.
The first item (which is a fieldset) is being recognised as being a group but the legend is not read out at all.
When the virtual cursor reaches the fieldset, the legend should be read out. (Like in the second example on the same page.)
When form elements are grouped with a fieldset, it's usually because their own labels don't make sense out of context. The context is usually given with the legend. For example a group of two radio buttons saying "Yes" and "No" doesn't make sense without the legend which might say "Do you already have an account?". Or three input fields labelled "Day", "Month" and "Year" won't make sense without a legend saying "What is your date of birth?".
You can still read the legend by arrowing up or down or tabbing to the inputs, but some VO users will be used to the shortcuts and might not explore other options.
The above is the description for macOS. When using iOS, put the rotor on iOS to 'Form Controls' and swipe down. The first item is the first radio button and only its label is being read out (when the legend is within the main element). The first item should instead be read out together with the legend before its label (as with the second example within a div).
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=148675
Date: 2015-09-01
Reported by: Robin Whittleton (@robinwhittleton)
[Robin] did some research on how radios and checkboxes resize in various browsers: https://gdstechnology.blog.gov.uk/2015/08/27/making-radio-buttons-and-checkboxes-easier-to-use/
It appears that on OS X by default radios and checkboxes are fixed to either a normal or a small size (<14px). Screenshots:
Safari 8: https://gdstechnology.blog.gov.uk/wp-content/uploads/sites/31/2015/08/osx_10.10_safari.png
Safari 9: https://gdstechnology.blog.gov.uk/wp-content/uploads/sites/31/2015/08/osx_10.11_safari.png
Chrome: https://gdstechnology.blog.gov.uk/wp-content/uploads/sites/31/2015/08/osx_10.10_chrome.png
Firefox makes an attempt to resize if requested but looks blurry, presumably because it’s only using the one raster image:
https://gdstechnology.blog.gov.uk/wp-content/uploads/sites/31/2015/08/osx_10.10_firefox.png
It’s possible to get one size bigger by tricking Safari into using the @2x radio image using transform:scale(2), but this only seems to work on non-retina machines (see Lea Verou’s bug #58524).
It would be great to be able to resize radios and checkboxes to fit the text around them. Our workaround is to handroll custom inputs, but these require extra maintenance and only work for us rather than the whole development community. Is Webkit on OS X tied to raster inputs, and if so is there work in progress to update these to vectors and unlock the size?
It’s worth pointing out that Windows (desktop and mobile), Android and iOS all have vector widgets for checkboxes and radios; OS X is lagging here.
Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1270163
Date: 2016-05-04
Reported by: Robin Whittleton (@robinwhittleton)
Related to: alphagov/govuk_elements#227
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160503030421
<details> element containing a <summary> elementdisplay:inline-block;The summary’s associated arrow disappears.
No change to the arrow.
The problem arises from the summary’s default display of list-item. As the arrow is a list marker[1], styling the summary as not a list item removes the marker.
Our use case is that the default focus outline for the summary as a list-item is full width, which is pretty ugly and not the default functionality for a trigger element (i.e. button, link, etc). Chrome allows us to set summary { display:inline-block; } which makes the focus outline shrinkwrap the text content of the summary.
[1] https://dxr.mozilla.org/mozilla-central/source/layout/style/res/html.css#776
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=208050#add_comment
Date: 2020-02-21
Reported by: @hannalaakso and @NickColley
Related to: alphagov/govuk-frontend#1696
The hint text for the aria-describedby on the input type="checkbox" supersedes the hint text for the aria-describedby on the fieldset. So the user only gets one hint read to them when they jump to the input through the tab index – the one on the input, rather than the legend.
<fieldset aria-describedby="confirm-nationality-hint">
<legend>
What is your nationality?
</legend>
<span id="confirm-nationality-hint">
Select all options that are relevant to you.
</span>
<br>
<input id="confirm-nationality" name="confirm-nationality" type="checkbox" value="british-nationality" aria-describedby="confirm-nationality-item-hint">
<label for="confirm-nationality">British</label>
<span id="confirm-nationality-item-hint" class="govuk-hint govuk-checkboxes__hint">
including English, Scottish, Welsh and Northern Irish
</span>
<br>
<input name="confirm-nationality" type="checkbox" value="irish-nationality" aria-describedby="confirm-nationality-2-item-hint">
<label class="govuk-label govuk-checkboxes__label" for="confirm-nationality-2">Irish</label>
<span id="confirm-nationality-2-item-hint" class="govuk-hint govuk-checkboxes__hint">
including from Northern Ireland
</span>
<br>
<input id="confirm-nationality-3" name="confirm-nationality" type="checkbox" value="other-country-nationality" data-aria-controls="conditional-confirm-nationality-3">
<label for="confirm-nationality-3">Citizen of a different country</label>
</fieldset>JSBIN: https://output.jsbin.com/juyaquq
The legend is announced, followed by the legend hint, then the input and finally the input hint.
The legend is announced, then the input and finally the input hint.
Upstream bug: nvaccess/nvda#9874
Date: 2019-07-05
Reported by: Tom Byers
Related to: Not applicable
Images with empty alt text in HTML emails should be treated like those in HTML web pages and ignored. When they appear in HTML emails, through the WIndows 10 Mail app, NVDA is not ignoring them and instead announces the URL of the image resource.
Steps to reproduce:
The image should be ignored.
NVDA announces the <img> as 'graphic'.
Upstream bug: FreedomScientific/standards-support#80
Date: 2018-05-09
Reported by: Alex Ju
JAWS does not announce description as associated with aria-describedby for a fieldset that contains text inputs.
Example:
We'd expect it to announce the description (basically to behave the same it does with a fieldset that contains radios or checkboxes - see example below)
It doesn't announce the description.
https://codepen.io/alex-ju/full/wjyrVe/
If role="group" is added to the fieldset, the description is being announced, but also the legend is being repeated which becomes too verbose.
https://codepen.io/alex-ju/full/PeQOOO/
We used this approach as a workaround in our code.
JAWS 18.0.4534 and 17.0.2729
Windows 10 Pro
Internet Explorer (IE) 11.371
Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1456461
Date: 2018-04-24
Reported by: Anika Henke
Related to: n/a
Form validates in screen readers despite 'novalidate' attribute.
This does not happen when testing the same page with NVDA or JAWS in IE11 (or with VoiceOver in Safari).
NVDA and JAWS both do an inline validation and immediately announce "invalid entry" when tabbing to a required input.
Screen readers shouldn't announce that the entry is invalid as there is nothing to validate when the 'novalidate' attribute is present on the form.
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=198963
Date: 2019-07-18
Reported by: Nick Colley
Related to: alphagov/govuk-design-system#902
When an anchor link is read out to a user, it's not clear if this will take them to a new page or somewhere in the same page.
“ I found it highly challenging to understand which links were standard links and which would move my focus down the page as both were located within the header.”
Anchor links that jump to content within the page should have a suffix of 'same page link' as is consistent with JAWS
Anchor links that jump to content within the page do not indicate that they're in page links
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=185246
Date: 2018-05-03
Reported by: Oliver Byford
Related to: alphagov/govuk-frontend#681
Given the following HTML within a valid HTML5 document:
<form>
<fieldset aria-describedby="hint error">
<legend>
<h1>Have you changed your name?</h1>
</legend>
<span id="hint">This includes changing your last name or spelling your name differently.</span>
<span id="error">Choose yes or no</span>
<input name="changed_name" id="yes" type="radio" value="yes" >
<label for="yes">Yes</label>
<input name="changed_name" id="no" type="radio" value="no">
<label for="no">No</label>
</fieldset>
</form>
When focussing the first radio input ("Yes") in the fieldset, Voiceover should include the text content of any element(s) associated with the containing fieldset (using aria-describedby):
"Yes, radio button, 1 of 2, Have you changed your name? This includes changing your last name or spelling your name differently. Choose yes or no.
You are currently on a radio button, 1 of 2, inside of a group. To select this option press Control-Option-Space"
This is the behaviour currently exhibited by iOS 10/11, and would be consistent with other assistive technologies (as tested with JAWS 18, NVDA).
When focussing the first radio input in a fieldset, Voiceover announces:
"Yes, radio button, 1 of 2, Have you changed your name?
You are currently on a radio button, 1 of 2, inside of a group. To select this option press Control-Option-Space"
As tested in Safari 11 and Safari Technology Preview 11.2 on macOS 10.13.4.
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=180866
Date: 2017-12-15
Reported by: Anika Henke
Related to: alphagov/govuk_elements#572
VoiceOver with Safari on iOS announces the wrong state (collapsed or expanded) when the element was just collapsed. It announces the correct state when swiping forwards and back again.
On step 4 VoiceOver says "Open this, collapsed", although the section is expanded.
VoiceOver should say "Open this, expanded" like it does on step 6, or like it does in macOS on step 4.
Upstream bug: https://openradar.appspot.com/radar?id=4938627352100864
Date: 2016-11-24
Reported by: Oliver Byford
Related to: -
Voiceover automatically expands "Gov." to "Governor" – presumably to handle cases like "Gov. Jerry Brown". However, it does this even if the period is followed by further alphabetical characters as in "GOV.UK" or "GOV.AU" – which seems to be a common pattern for (e.g.) government websites.
Voiceover would read:
[Skip to main content, link]
Gov UK, [link, banner, landmark]
Welcome to Gov UK
The best place to find government services and information
Simpler, clearer, faster
Search Gov UK
[...]
Or a sensible variant thereof (e.g. pronouncing the period in GOV.UK as it would in a url)
Voiceover reads:
[Skip to main content, link]
Governor, UK, [link, banner, landmark]
Welcome to Governor, UK
The best place to find government services and information. Simpler, clearer, faster.
Search Governor, UK.
[...]
iOS 10.1 [14B72]
Cannot reproduce on on OS X 10.11.6 (15G1108) or macOS 10.12.2b (16C48b) – this only appears to happen on iOS.
We believe (anecdotally) that this may have been happening since at least iOS 9.
iPhone 6s, Voiceover enabled, Daniel (Enhanced) Voice
Upstream bug: nvaccess/nvda#9675
Date: 2019-06-05
Reported by: Oliver Byford
Related to: alphagov/govuk-frontend#1408
With an HTML document containing the following markup, open the elements list using NVDA + F7 and select the 'Form fields' type.
<input type="text" id="text-field">
<label for="text-field">Text field</label>
<br><br>
<input type="number" id="number-field">
<label for="number-field">Number field</label>The elements list does not include the text from the label associated with the number field; instead reporting it as 'unlabeled':
The elements list should include both fields with the text from the associated label:
Installed
2019.1.1
Windows 10; Version 1607; Build 14393. (VirtualBox VM)
Firefox 67.0.1
N/A
Yes
N/A
Upstream bug: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/11826078/
Date: 2018-04-28
Reported by: Jani Kraner
Select box - colour contrast is only 2.9:1 between the highlighted (white) text and pale blue background - this is in Windows 10 and checked with both IE and Firefox
Example select box where this happens: https://design-system.service.gov.uk/components/select/default/index.html
This is the default look of the Windows IE/Edge select boxes and not part of GOV.UK Frontend.
Darker background colour would need to be implemented by vendor
Closed as won't fix. We've done a fix in our codebase here: https://github.com/alphagov/govuk-frontend/blob/master/src/components/select/_select.scss#L23-L25
Response:
Hello,
Thank you for providing this update. If you need better accessibility to the browser elements, please consider using Windows high-contrast settings.
https://support.microsoft.com/en-us/help/13862/windows-use-high-contrast-mode
Best Wishes,
The MS Edge Team
Upstream bug: https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c53
Date: 2019-07-12
Reported by: Nick Colley
Related to: alphagov/accessible-autocomplete#325
The accessible autocomplete component sets autocomplete="off" so that Chrome's interface does not conflict with the components interface.
Chrome does not show suggestions when autocomplete attribute is set to off
Chrome shows suggestions when autocomplete attribute is set to off
Upstream bug: https://bugs.chromium.org/p/chromium/issues/detail?id=626670
Date: 2017-08-03
Reported by: Robin Whittleton (@robinwhittleton)
https://www.gov.uk/register-british-citizen
Normal font rendering
We apply font-size-adjust to the page. This is currently available in Chrome behind the experimental features flag. On hiDPI screens on Linux and Android there’s a rendering bug that makes the table unreadable. Attached is a screenshot of the problem (taken from browserstack.com on a Nexus 5 with Android 6). We’ve had reports from users on that mobile platform, and on Chrome 52 beta on Ubuntu on a 4K screen.
Does it occur on multiple sites: N/A
Is it a problem with a plugin? No
Did this work before? No
Does this work in other browsers? Yes
Chrome version: Version 51.0.2704.103 (64-bit) Channel: n/a
OS Version: OS X 10.11
Flash Version:
This has been tested to work OK in Firefox and in Chrome on OS X on a 4K screen.
Upstream bug: https://bugs.chromium.org/p/chromium/issues/detail?id=686084
Date: 2017-01-27
Reported by: Oliver Byford
Related to: -
Example URL:
http://codepen.io/36degrees/pen/MJOgNj
Steps to reproduce the problem:
What is the expected behavior?
The shadow should not affect the layout of the element.
What went wrong?
The elements layout is adjusted such that its position allows for the left and top shadows of the element to be rendered on screen.
Does it occur on multiple sites: N/A
Is it a problem with a plugin? No
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 56.0.2924.76 Channel: stable
OS Version: OS X 10.12.2
Flash Version: Shockwave Flash 24.0 r0
Not happening in Safari or Firefox
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=179011
Date: 2017-10-30
Reported by: Anika Henke
Related to: n/a
In iOS 11 you can currently not follow any in-page links to anything but inputs.
The focus moves to the correct element for a split second and then moves back onto the link that was clicked on.
The focus should go and stay where the link pointed to.
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=171006
Date: 2017-04-19
Reported by: Anika Henke
Related to: alphagov/govuk_elements#511
When posting a form (presumably to the same page), the next page that loads always focusses on the submit button. That only happens in Safari (not Chrome or Firefox) when VoiceOver is active. It doesn't happen when VoiceOver is disabled.
The focus is on the submit button. There is sometimes a short delay and the error message is focussed first before the focus quickly moves onto the submit button, most often too quickly to read anything out loud, sometimes it reads the first word before moving to the button.
The focus should be on the "error message". Even without the JavaScript that adds focus to the error message, the focus should not be on anything else.
It works as expected when VoiceOver is switched off, or when VoiceOver is used with Chrome or Firefox, or when just the space or enter key is used to submit the form. But VO key + space is what VoiceOver tells you to use when focussing on a button.
When there are errors in a form, you would usually want to inform people about it. That can be done in multiple ways. When done by focussing on the error alert box to be read out immediately to screen readers, that focus will be removed from the alert box to the button. That means VoiceOver users who cannot see the screen will have no way of knowing an error appeared.
Another example where you can see that in action is on http://govuk-elements.herokuapp.com/errors/example-form-validation-multiple-questions. Submit the form, an alert box will appear but will not be announced as the focus is on the button. That will happen after the first submit.
This seems to only happen when the URL after the submit is the same as before. Posting to the same URL will always show that bug. When a get is used, this seems to only be true as long as the parameters in the URL stay the same. That is probably why the example form in the steps to reproduce needs to be submitted twice. When accessing the page with the empty text input in the URL [http://output.jsbin.com/toxarul?text=], the bug appears after the first submit. When filling in the form field with something, e.g. "test", the bug does not appear, unless you fill it again with the very same word and submit again.
This bug is probably not present in Safari on iOS, only on OS X. I say "probably" because there is another bug on iOS which moves the focus to somewhere else, which makes that difficult to verify. But that's another story...
Upstream bug: nvaccess/nvda#6209 (comment)
Date: 2018-10-09
Reported by: Oliver Byford
Related to: alphagov/govuk-frontend#1056 (comment)
Given the following HTML snippet:
<a href="#textinput">Link to input</a>
<label id="textinput-label" for="textinput">Label for text input</label>
<span class="error" id="textinput-error">Error for text input</span>
<input id="textinput" type="text" aria-describedby="textinput-error" value="Current value">
The expected behaviour would mirror NVDA's existing behaviour when focussing an input by tabbing to it:
The actual behaviour is that NVDA omits both the label and the error message (associated using aria-describedby):
In our testing this same problem exists when linking to all types of inputs, including textareas, selects, radio buttons and checkboxes.
Upstream bug: https://bugs.chromium.org/p/chromium/issues/detail?id=666674
Date: 2016-11-18
Reported by: Tom Byers
Related to: alphagov/govuk_frontend_toolkit#271
When zooming the page, text with font-size-adjust applied do not scale.
The text should scale to the zoom level applied.
The text size stayed the same and ignored the scaling applied by the zoom level.
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=191748
Date: 2018-11-16
Reported by: Oliver Byford
Related to: alphagov/govuk-frontend#1056 (comment)
Given the following markup:
<a href="#checkboxes-1">Link to checkboxes</a><br>
<a href="#radios-1">Link to radios</a><br>
<br><br>
<fieldset aria-describedby="checkboxes-description">
<legend>Legend for checkboxes</legend>
<span id="checkboxes-description">
Description for checkboxes
</span>
<br>
<input id="checkboxes-1" name="checkboxes" type="checkbox" value="one">
<label for="checkboxes-1">
One
</label>
<input id="checkboxes-2" name="checkboxes" type="checkbox" value="two">
<label for="checkboxes-2">
Two
</label>
</fieldset>
<br><br>
<fieldset aria-describedby="radios-description">
<legend>Legend for radios</legend>
<span id="radios-description">
Description for radios
</span>
<br>
<input id="radios-1" name="radios" type="radio" value="one">
<label for="radios-1">
One
</label>
<input id="radios-2" name="radios" type="radio" value="two">
<label for="radios-2">
Two
</label>
</fieldset>
Focus the link to each input type and activate it by double-tapping.
Voiceover should announce the same context that it announces when reaching the first checkbox in the fieldset by swiping in either direction through the document, including the label, field type, legend and any description:
"Legend for checkboxes, Description for checkboxes, Two, tickbox, unticked. Description for checkboxes. Double-tap to toggle setting."
(The description is repeated here, which is probably another bug...)
Voiceover does not include the legend as part of the announcement, and only announces the ticked state:
"Unticked"
Voiceover should announce the same context that it announces when reaching the first checkbox in the fieldset by swiping in either direction through the document, including the label, field type, legend and any description:
"Legend for radios, Description for radios, Two, radio button, unticked. Two of two. Description for radios."
(Again, the description is repeated here)
Voiceover does not include the legend as part of the announcement, and only announces the ticked state:
"Unticked"
Tested in iOS 12.1 (16B92) on an iPhone X (A1901)
This may be related to https://bugs.webkit.org/show_bug.cgi?id=191746.
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=191746
Date: 2018-11-16
Reported by: Oliver Byford
Related to: alphagov/govuk-frontend#1056 (comment)
Given the following markup:
<a href="#textinput">Link to input type="text"</a><br>
<a href="#textarea">Link to textarea</a>
<br><br>
<label for="textinput">Label for text input</label><br>
<span id="textinput-description">Description for text input</span><br>
<input id="textinput" type="text" aria-describedby="textinput-description" value="Foo">
<br><br>
<label for="textarea">Label for textarea</label><br>
<span id="textarea-description">Description for textarea</span><br>
<textarea id="textarea" name="textarea" rows="10" cols="50" aria-describedby="textarea-description">Bar</textarea>
Focus the link to each input type and activate it by double-tapping.
Voiceover should announce the same context that it announces when focusing the field by swiping through the document, including the label, field type, current value, and any description:
"Label for text input, text field, foo. Description for text input. Double-tap to edit"
The VO cursor moves to the target input, but nothing is announced.
Voiceover should announce the same context that it announces when focusing the field by swiping through the document, including the label, field type, current value, and any description:
"Label for textarea, multi-line text field, bar. Description for textarea. Double-tap to edit"
The VO cursor moves to the target input, but nothing is announced.
Tested in iOS 12.1 (16B92) on an iPhone X (A1901)
Upstream bug: FreedomScientific/standards-support#372
Date: 2020-02-21
Reported by: @hannalaakso and @NickColley
Related to: alphagov/govuk-frontend#1696
Test case: https://output.jsbin.com/jorocat
<a href="#">Link in page</a>
<br>
<button>
Open all<span class="visually-hidden"> sections</span>
</button>
<br>
<a href="#">
Delete<span class="visually-hidden"> name</span>
</a>.visually-hidden {
position: absolute !important;
width: 1px !important;
height: 1px !important;
margin: 0 !important;
padding: 0 !important;
overflow: hidden !important;
clip: rect(0 0 0 0) !important;
-webkit-clip-path: inset(50%) !important;
clip-path: inset(50%) !important;
border: 0 !important;
white-space: nowrap !important;
}JAWS: 2020
Chrome version: 79.0.3945.130
Announces "Delete name"
Announces "Deletename"
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=191743
Date: 2018-11-16
Reported by: Oliver Byford
Related to: alphagov/govuk-frontend#1056 (comment)
Given the following markup:
<input id="checkbox-bar" name="foo" type="checkbox" value="bar">
<label for="checkbox-bar">
Foo
</label>
<br>
<input id="checkbox-baz" name="foo" type="checkbox" value="baz">
<label for="checkbox-baz">
Bar
</label>
Focus either checkbox.
This behaviour is also present in Safari Technology Preview release 70.
Voiceover should announce the label once, e.g.
"Foo, unticked, checkbox"
Voiceover announces the label twice, e.g.
"Foo, Foo, unticked, checkbox"
Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=191742
Date: 2018-11-16
Reported by: Oliver Byford
Related to: alphagov/govuk-frontend#1056 (comment)
Given the following markup:
<a href="#input">Link to input</a>
<fieldset aria-describedby="fieldset-description">
<legend>Legend for multiple inputs</legend>
<span id="fieldset-description">
Description for multiple inputs
</span>
<label for="input">
Label for input
</label>
<input id="input" name="input">
</fieldset>
Focus the 'link to input' and use the Ctrl-Option-Space key to follow the link, as instructed.
Voiceover should announce the same things that it announces when following the link using the Enter key, including the legend:
"Label for input, edit text, Legend for multiple inputs, group. Description for multiple inputs, You are currently on a text field. To enter text in this field, type"
(The legend is actually announced twice in Safari 12, but this appears to be fixed in Safari Technology Preview release 70)
Voiceover does not include the legend as part of the announcement, although it does include the description associated using aria-describedby:
"Label for input, edit text. Description for multiple inputs, You are currently on a text field. To enter text in this field, type"
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.