From 13bd2b87224720bab3a313d92b59e518df6b05a4 Mon Sep 17 00:00:00 2001
From: "Patrick H. Lauke" <redux@splintered.co.uk>
Date: Fri, 3 Jul 2020 21:37:31 +0100
Subject: [PATCH 1/6] Expand advice for anchor-based controls

---
 site/docs/4.5/components/forms.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/site/docs/4.5/components/forms.md b/site/docs/4.5/components/forms.md
index 651046c270bc..0f09f5c1f713 100644
--- a/site/docs/4.5/components/forms.md
+++ b/site/docs/4.5/components/forms.md
@@ -732,7 +732,7 @@ Add the `disabled` attribute to a `<fieldset>` to disable all the controls withi
 {% capture callout %}
 ##### Caveat with anchors
 
-By default, browsers will treat all native form controls (`<input>`, `<select>` and `<button>` elements) inside a `<fieldset disabled>` as disabled, preventing both keyboard and mouse interactions on them. However, if your form also includes `<a ... class="btn btn-*">` elements, these will only be given a style of `pointer-events: none`. As noted in the section about [disabled state for buttons]({{ site.baseurl }}/docs/{{ site.docs_version }}/components/buttons/#disabled-state) (and specifically in the sub-section for anchor elements), this CSS property is not yet standardized and isn't fully supported in Internet Explorer 10, and won't prevent keyboard users from being able to focus or activate these links. So to be safe, use custom JavaScript to disable such links.
+By default, browsers will treat all native form controls (`<input>`, `<select>` and `<button>` elements) inside a `<fieldset disabled>` as disabled, preventing both keyboard and mouse interactions on them. However, if your form also includes `<a ... class="btn btn-*">` elements, these will only be given a style of `pointer-events: none`. As noted in the section about [disabled state for buttons]({{ site.baseurl }}/docs/{{ site.docs_version }}/components/buttons/#disabled-state) (and specifically in the sub-section for anchor elements), this CSS property is not yet standardized and isn't fully supported in Internet Explorer 10. The anchor-based controls will also still be focusable and operable using the keyboard - you will need to manually modify these controls further (adding `tabindex="-1"` to prevent them from receiving focus, and `aria-disabled="disabled"` to signal their state to assistive technologies).
 {% endcapture %}
 {% include callout.html content=callout type="warning" %}
 

From ec91baaa452e432277204d0944cc40268911e7ea Mon Sep 17 00:00:00 2001
From: "Patrick H. Lauke" <redux@splintered.co.uk>
Date: Fri, 3 Jul 2020 21:37:50 +0100
Subject: [PATCH 2/6] Expand accessibility note in input group

---
 site/docs/4.5/components/input-group.md | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/site/docs/4.5/components/input-group.md b/site/docs/4.5/components/input-group.md
index cdbfa794a69a..5ac802b80f4d 100644
--- a/site/docs/4.5/components/input-group.md
+++ b/site/docs/4.5/components/input-group.md
@@ -370,6 +370,8 @@ Input groups include support for custom selects and custom file inputs. Browser
 
 ## Accessibility
 
-Screen readers will have trouble with your forms if you don't include a label for every input. For these input groups, ensure that any additional label or functionality is conveyed to assistive technologies.
+Ensure that all form controls have an appropriate accessible name, so that their purpose can be conveyed to users of assistive technologies. The simplest way to achieve this is to use a `<label>` element, or - in the case of buttons - to include sufficiently descriptive text as part of the `<button> ... </button>` content.
 
-The exact technique to be used (`<label>` elements hidden using the `.sr-only` class, or use of the `aria-label` and `aria-labelledby` attributes, possibly in combination with `aria-describedby`) and what additional information will need to be conveyed will vary depending on the exact type of interface widget you're implementing. The examples in this section provide a few suggested, case-specific approaches.
+For situations where it's not possible to include a visible `<label>` or appropriate text content, there are alternative ways of still providing an accessible name, such as `<label>` elements hidden using the `.sr-only` class, pointing to an existing element that can act as a label using `aria-labelledby`, providing a `title` attribute, or explicitly setting the accessible name on an element using `aria-label`. If none of these are present, assistive technologies may resort to using the `placeholder` attribute as a fallback for the accessible name on `<input>` and `<textarea>` elements. The examples in this section provide a few suggested, case-specific approaches.
+
+However, note that while using visually hidden content (`.sr-only`, `aria-label`, and even `placeholder` content, which disappears once a form field has content) will benefit assistive technology users, a lack of visible label text may still be problematic for certain users. Some form of visible label is generally the best approach, both for accessibility and usability.

From ea6575ff7309addd64d8e9dee1b04949835c8d4e Mon Sep 17 00:00:00 2001
From: "Patrick H. Lauke" <redux@splintered.co.uk>
Date: Fri, 3 Jul 2020 21:43:54 +0100
Subject: [PATCH 3/6] Correct statement about validation, fix server example

---
 site/docs/4.5/components/forms.md | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/site/docs/4.5/components/forms.md b/site/docs/4.5/components/forms.md
index 0f09f5c1f713..03dc7a044bd2 100644
--- a/site/docs/4.5/components/forms.md
+++ b/site/docs/4.5/components/forms.md
@@ -748,7 +748,7 @@ While Bootstrap will apply these styles in all browsers, Internet Explorer 11 an
 Provide valuable, actionable feedback to your users with HTML5 form validation–[available in all our supported browsers](https://caniuse.com/#feat=form-validation). Choose from the browser default validation feedback, or implement custom messages with our built-in classes and starter JavaScript.
 
 {% capture callout %}
-We currently recommend using custom validation styles, as native browser default validation messages are not consistently exposed to assistive technologies in all browsers (most notably, Chrome on desktop and mobile).
+We are aware that currently the client-side custom validation styles and tooltips are not accessible, since they are not exposed to assistive technologies. While we work on a solution, we'd recommend either using the server-side option or the default browser validation method.
 {% endcapture %}
 {% include callout.html content=callout type="warning" %}
 
@@ -912,6 +912,8 @@ While these feedback styles cannot be styled with CSS, you can still customize t
 
 We recommend using client-side validation, but in case you require server-side validation, you can indicate invalid and valid form fields with `.is-invalid` and `.is-valid`. Note that `.invalid-feedback` is also supported with these classes.
 
+For invalid fields, ensure that the invalid feedback/error message is associated with the relevant form field using `aria-describedby` (noting that this attribute allows more than one `id` to be referenced, in case the field already points to additional form text).
+
 {% capture example %}
 <form>
   <div class="form-row">
@@ -933,36 +935,36 @@ We recommend using client-side validation, but in case you require server-side v
   <div class="form-row">
     <div class="col-md-6 mb-3">
       <label for="validationServer03">City</label>
-      <input type="text" class="form-control is-invalid" id="validationServer03" required>
-      <div class="invalid-feedback">
+      <input type="text" class="form-control is-invalid" id="validationServer03" aria-describedby="validationServer03Feedback" required>
+      <div id="validationServer03Feedback" class="invalid-feedback">
         Please provide a valid city.
       </div>
     </div>
     <div class="col-md-3 mb-3">
       <label for="validationServer04">State</label>
-      <select class="custom-select is-invalid" id="validationServer04" required>
+      <select class="custom-select is-invalid" id="validationServer04" aria-describedby="validationServer04Feedback" required>
         <option selected disabled value="">Choose...</option>
         <option>...</option>
       </select>
-      <div class="invalid-feedback">
+      <div id="validationServer04Feedback" class="invalid-feedback">
         Please select a valid state.
       </div>
     </div>
     <div class="col-md-3 mb-3">
       <label for="validationServer05">Zip</label>
-      <input type="text" class="form-control is-invalid" id="validationServer05" required>
-      <div class="invalid-feedback">
+      <input type="text" class="form-control is-invalid" id="validationServer05" aria-describedby="validationServer05Feedback" required>
+      <div id="validationServer05Feedback" class="invalid-feedback">
         Please provide a valid zip.
       </div>
     </div>
   </div>
   <div class="form-group">
     <div class="form-check">
-      <input class="form-check-input is-invalid" type="checkbox" value="" id="invalidCheck3" required>
+      <input class="form-check-input is-invalid" type="checkbox" value="" id="invalidCheck3" aria-describedby="invalidCheck3Feedback" required>
       <label class="form-check-label" for="invalidCheck3">
         Agree to terms and conditions
       </label>
-      <div class="invalid-feedback">
+      <div  id="invalidCheck3Feedback" class="invalid-feedback">
         You must agree before submitting.
       </div>
     </div>

From 747cb1e798d5d9b9f3b45105bdf6f7330bcacb06 Mon Sep 17 00:00:00 2001
From: "Patrick H. Lauke" <redux@splintered.co.uk>
Date: Fri, 3 Jul 2020 21:44:25 +0100
Subject: [PATCH 4/6] Tweak label > accessible name

---
 site/docs/4.5/components/forms.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/site/docs/4.5/components/forms.md b/site/docs/4.5/components/forms.md
index 03dc7a044bd2..382a5f574fa3 100644
--- a/site/docs/4.5/components/forms.md
+++ b/site/docs/4.5/components/forms.md
@@ -258,7 +258,7 @@ Group checkboxes or radios on the same horizontal row by adding `.form-check-inl
 
 ### Without labels
 
-Add `.position-static` to inputs within `.form-check` that don't have any label text. Remember to still provide some form of label for assistive technologies (for instance, using `aria-label`).
+Add `.position-static` to inputs within `.form-check` that don't have any label text. Remember to still provide some form of accessible name for assistive technologies (for instance, using `aria-label`).
 
 {% capture example %}
 <div class="form-check">

From f06ea9b1f7c39344eb29b7dda422af9bd5964ded Mon Sep 17 00:00:00 2001
From: Mark Otto <markd.otto@gmail.com>
Date: Sat, 11 Jul 2020 19:39:40 -0700
Subject: [PATCH 5/6] Update forms.md

---
 site/docs/4.5/components/forms.md | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/site/docs/4.5/components/forms.md b/site/docs/4.5/components/forms.md
index 382a5f574fa3..4a8f62947097 100644
--- a/site/docs/4.5/components/forms.md
+++ b/site/docs/4.5/components/forms.md
@@ -732,7 +732,9 @@ Add the `disabled` attribute to a `<fieldset>` to disable all the controls withi
 {% capture callout %}
 ##### Caveat with anchors
 
-By default, browsers will treat all native form controls (`<input>`, `<select>` and `<button>` elements) inside a `<fieldset disabled>` as disabled, preventing both keyboard and mouse interactions on them. However, if your form also includes `<a ... class="btn btn-*">` elements, these will only be given a style of `pointer-events: none`. As noted in the section about [disabled state for buttons]({{ site.baseurl }}/docs/{{ site.docs_version }}/components/buttons/#disabled-state) (and specifically in the sub-section for anchor elements), this CSS property is not yet standardized and isn't fully supported in Internet Explorer 10. The anchor-based controls will also still be focusable and operable using the keyboard - you will need to manually modify these controls further (adding `tabindex="-1"` to prevent them from receiving focus, and `aria-disabled="disabled"` to signal their state to assistive technologies).
+Browsers treat all native form controls (`<input>`, `<select>`, and `<button>` elements) inside a `<fieldset disabled>` as disabled, preventing both keyboard and mouse interactions on them.
+
+However, if your form also includes custom button-like elements such as `<a ... class="btn btn-*">`, these will only be given a style of `pointer-events: none`. As noted in the section about [disabled state for buttons]({{ site.baseurl }}/docs/{{ site.docs_version }}/components/buttons/#disabled-state) (and specifically in the sub-section for anchor elements), this CSS property is not yet standardized and isn't fully supported in Internet Explorer 10. The anchor-based controls will also still be focusable and operable using the keyboard. You must manually modify these controls by adding `tabindex="-1"` to prevent them from receiving focus and `aria-disabled="disabled"` to signal their state to assistive technologies.
 {% endcapture %}
 {% include callout.html content=callout type="warning" %}
 
@@ -912,7 +914,7 @@ While these feedback styles cannot be styled with CSS, you can still customize t
 
 We recommend using client-side validation, but in case you require server-side validation, you can indicate invalid and valid form fields with `.is-invalid` and `.is-valid`. Note that `.invalid-feedback` is also supported with these classes.
 
-For invalid fields, ensure that the invalid feedback/error message is associated with the relevant form field using `aria-describedby` (noting that this attribute allows more than one `id` to be referenced, in case the field already points to additional form text).
+For invalid fields, ensure that the invalid feedback/error message is associated with the relevant form field using `aria-describedby`. This attribute allows more than one `id` to be referenced, in case the field already points to additional form text.
 
 {% capture example %}
 <form>

From e6fbd2a1abc4e40ceafe1fe385830cb4892225db Mon Sep 17 00:00:00 2001
From: Mark Otto <markd.otto@gmail.com>
Date: Sat, 11 Jul 2020 19:41:45 -0700
Subject: [PATCH 6/6] Update input-group.md

---
 site/docs/4.5/components/input-group.md | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/site/docs/4.5/components/input-group.md b/site/docs/4.5/components/input-group.md
index 5ac802b80f4d..606bf4b75222 100644
--- a/site/docs/4.5/components/input-group.md
+++ b/site/docs/4.5/components/input-group.md
@@ -370,8 +370,15 @@ Input groups include support for custom selects and custom file inputs. Browser
 
 ## Accessibility
 
-Ensure that all form controls have an appropriate accessible name, so that their purpose can be conveyed to users of assistive technologies. The simplest way to achieve this is to use a `<label>` element, or - in the case of buttons - to include sufficiently descriptive text as part of the `<button> ... </button>` content.
+Ensure that all form controls have an appropriate accessible name so that their purpose can be conveyed to users of assistive technologies. The simplest way to achieve this is to use a `<label>` element, or—in the case of buttons—to include sufficiently descriptive text as part of the `<button>...</button>` content.
 
-For situations where it's not possible to include a visible `<label>` or appropriate text content, there are alternative ways of still providing an accessible name, such as `<label>` elements hidden using the `.sr-only` class, pointing to an existing element that can act as a label using `aria-labelledby`, providing a `title` attribute, or explicitly setting the accessible name on an element using `aria-label`. If none of these are present, assistive technologies may resort to using the `placeholder` attribute as a fallback for the accessible name on `<input>` and `<textarea>` elements. The examples in this section provide a few suggested, case-specific approaches.
+For situations where it's not possible to include a visible `<label>` or appropriate text content, there are alternative ways of still providing an accessible name, such as:
 
-However, note that while using visually hidden content (`.sr-only`, `aria-label`, and even `placeholder` content, which disappears once a form field has content) will benefit assistive technology users, a lack of visible label text may still be problematic for certain users. Some form of visible label is generally the best approach, both for accessibility and usability.
+- `<label>` elements hidden using the `.visually-hidden` class
+- Pointing to an existing element that can act as a label using `aria-labelledby`
+- Providing a `title` attribute
+- Explicitly setting the accessible name on an element using `aria-label`
+
+If none of these are present, assistive technologies may resort to using the `placeholder` attribute as a fallback for the accessible name on `<input>` and `<textarea>` elements. The examples in this section provide a few suggested, case-specific approaches.
+
+While using visually hidden content (`.sr-only`, `aria-label`, and even `placeholder` content, which disappears once a form field has content) will benefit assistive technology users, a lack of visible label text may still be problematic for certain users. Some form of visible label is generally the best approach, both for accessibility and usability.