Problem
Braintree Hosted Fields adds pattern="\d*" to the elements inside the hosted field iframes (at minimum on the number, cvv, and expirationDate fields). This causes a persistent validity.patternMismatch even when the field value is completely valid, because:
- The card number field is formatted with spaces (e.g. 4111 1111 1111 1111), which does not match \d*
- The expiration date field contains a / separator (e.g. 12/25), which does not match \d*
As a result, the browser's native ValidityState.patternMismatch is true on these inputs despite the values being correct from Braintree's own validation perspective (isValid: true).
Accessibility impact (critical)
Screen readers rely on the browser's native validity state to announce field status to users. Because patternMismatch is true, screen readers falsely announce these fields as invalid, even after the user has entered correct data. This directly misleads blind and visually impaired users.
This violates the following WCAG 2.2 success criteria:
- 1.3.1 Info and Relationships (Level A) — The programmatic state of the fields does not match their actual state
- 4.1.2 Name, Role, Value (Level A) — The validity value exposed to assistive technologies is incorrect
Affected user groups:
- Blind users (screen reader users)
- Low-vision users
- Users with cognitive disabilities
This was identified as a critical severity finding during a professional WCAG 2.2 accessibility audit.
Current behavior
- User enters a valid card number → Braintree marks it as isValid: true
- The input's validity.patternMismatch is true because the formatted value ("4111 1111 1111 1111") does not match pattern="\d*"
- Screen readers announce the field as invalid
Same issue for expiration date ("12/25" does not match \d*).
Proposed solution
Any of the following would resolve this issue:
-
Remove the pattern attribute entirely from Hosted Fields inputs. The inputmode="numeric" attribute (which is already present) is sufficient to trigger the numeric keyboard on mobile devices. The pattern attribute is redundant and actively harmful.
-
Use a pattern that matches the actual formatted values, e.g.:
- Card number: [\d ]* (digits and spaces)
- Expiration date: [\d/]* (digits and slash)
- CVV: \d* (digits only — this one is already correct)
-
Add pattern to the allowedAttributes list in both the external and internal (iframe-side) attribute validation, so consumers can call removeAttribute({ field: 'number', attribute: 'pattern' }) to opt out.
Environment
braintree-web: 3.134.0 (also verified the issue is present conceptually through 3.139.0 based on unchanged allowedAttributes in the source)
Tested in Chrome, Firefox, Safari
Problem
Braintree Hosted Fields adds pattern="\d*" to the elements inside the hosted field iframes (at minimum on the number, cvv, and expirationDate fields). This causes a persistent validity.patternMismatch even when the field value is completely valid, because:
As a result, the browser's native ValidityState.patternMismatch is true on these inputs despite the values being correct from Braintree's own validation perspective (isValid: true).
Accessibility impact (critical)
Screen readers rely on the browser's native validity state to announce field status to users. Because patternMismatch is true, screen readers falsely announce these fields as invalid, even after the user has entered correct data. This directly misleads blind and visually impaired users.
This violates the following WCAG 2.2 success criteria:
Affected user groups:
This was identified as a critical severity finding during a professional WCAG 2.2 accessibility audit.
Current behavior
Same issue for expiration date ("12/25" does not match \d*).
Proposed solution
Any of the following would resolve this issue:
Remove the pattern attribute entirely from Hosted Fields inputs. The inputmode="numeric" attribute (which is already present) is sufficient to trigger the numeric keyboard on mobile devices. The pattern attribute is redundant and actively harmful.
Use a pattern that matches the actual formatted values, e.g.:
Add pattern to the allowedAttributes list in both the external and internal (iframe-side) attribute validation, so consumers can call removeAttribute({ field: 'number', attribute: 'pattern' }) to opt out.
Environment
braintree-web: 3.134.0 (also verified the issue is present conceptually through 3.139.0 based on unchanged allowedAttributes in the source)
Tested in Chrome, Firefox, Safari