Minor bug fixes in forms and table sections & misc updates

content/carousels/styling.md

@@ -24,7 +24,7 @@ wcag_success_criteria:
 
 metafooter: true
 first_published: "May 2015"
-last_updated: 2018-08-30
+last_updated: 2024-05-13
 editors:
   - Eric Eggert: "https://www.w3.org/People/yatil/"
   - Shadi Abou-Zahra: "https://www.w3.org/People/shadi/"
@@ -44,7 +44,7 @@ Use appropriately sized buttons and links, and provide whitespace around them, t
 ![Example using semi-transparent background colors to ensure sufficient contrast.]({{ "/content-images/wai-tutorials/carousels/carousels-styling-contrast.png" | relative_url }}){:.left} Ensure sufficient contrast between the foreground and the background of text, links, and buttons. This can be a challenge when text or buttons are positioned on top of images. In that case, a (semi-) opaque background color can help to maintain the contrast regardless of the image used.
 
 
-{% include ednote.html note="The following paragraph was show in a side column before." %}For more information on contrast requirements, see [Provide sufficient contrast between foreground and background](https://www.w3.org/WAI/gettingstarted/tips/designing.html#provide-sufficient-contrast-between-foreground-and-background).
+{% include ednote.html note="The following paragraph was show in a side column before." %}For more information on contrast requirements, see [Provide sufficient contrast between foreground and background](/tips/designing/#provide-sufficient-contrast-between-foreground-and-background).
 
 ## Indicate Button Status
 
@@ -117,3 +117,7 @@ In the following example, a filled square is used for buttons associated with it
 {:/}
 
 {% include ednote.html note="The following paragraph was show in a side column before." %}A [working demo example](/tutorials/carousels/working-example/) for this code is available.
+
+## For smaller screens/small viewports
+Ensure all text is readable and not cut off or unnecessarily truncated. Make sure that [navigation buttons](/tutorials/carousels/functionality/#add-navigation-buttons) to control the slides are available, since some people cannot use swipe gestures.
+

content/changelog.md

@@ -27,6 +27,26 @@ This changelog lists substantive content edits. It does **not** list typo fixes
 {::nomarkdown}
 {% include box.html type="end" %}
 {:/}
+## May 2024
+In [Forms tutorial](/tutorials/forms/)
+* Fixing a broken link in [Form Instructions](/tutorials/forms/instructions/#placeholder-text)
+  * [GitHub PR #735](https://github.com/w3c/wai-tutorials/pull/735)
+* Fixing a color contrast issue in [Multi-page Forms](/tutorials/forms/multi-page/#using-the-html5-progress-element)
+  * [GitHub PR #732](https://github.com/w3c/wai-tutorials/pull/732)
+
+In [Tables tutorial](/tutorials/tables/)
+* Fixing a table header issue in [Tables with Multi-Level Headers](/tutorials/tables/multi-level/#table-with-multiple-column-headers-in-each-column)
+  * [GitHub PR #726](https://github.com/w3c/wai-tutorials/pull/726)
+
+In [Images tutorial](/tutorials/images/)
+* Updating link text in [An <code>alt</code> Decision Tree](/tutorials/images/decision-tree/)
+  * [GitHub PR #774](https://github.com/w3c/wai-tutorials/pull/774)
+
+Added notes about responsive design/smaller screen considerations to:
+* [Page Structure > Page Regions](/tutorials/page-structure/regions/)
+* [Menus > Structure](/tutorials/menus/structure/)
+* [Forms > Labeling Controls](/tutorials/forms/labels/)
+* [Carousels > Styling](/tutorials/carousels/styling/)
 
 ## February 2023
 

content/forms/instructions.md

@@ -35,7 +35,7 @@ wcag_techniques:
   - ARIA9
 
 metafooter: true
-last_updated: 2019-07-27
+last_updated: 2024-05-13
 editors:
   - Eric Eggert: "https://www.w3.org/People/yatil/"
   - Shadi Abou-Zahra: "https://www.w3.org/People/shadi/"
@@ -200,7 +200,7 @@ Placeholder text provides instructions or an example of the required data format
 
 While placeholder text provides valuable guidance for many users, **placeholder text is not a replacement for labels**. Assistive technologies, such as screen readers, do not treat placeholder text as labels. Moreover, at the time of writing this tutorial, placeholder text is not broadly supported across assistive technologies and not displayed in older web browsers.
 
-Note: Section [Hidden labels](labels.html#hidden) of this tutorial describes how to hide information visually but keep it available to assistive technology. This same approach can be used to avoid visual redundancy of displaying both labels and placeholder text. Be aware that this makes it very hard for users to review the form. To avoid this problem, JavaScript can be used to make labels appear visually (in the associated label element) above or beside the input that has focus.
+Note: The [Note on hiding elements](/tutorials/forms/labels/#note-on-hiding-elements) section of the Labeling Controls page describes how to hide information visually but keep it available to assistive technology. This same approach can be used to avoid visual redundancy of displaying both labels and placeholder text. Be aware that this makes it very hard for users to review the form. To avoid this problem, JavaScript can be used to make labels appear visually (in the associated label element) above or beside the input that has focus.
 
 {::nomarkdown}
 {% include box.html type="start" title="Example" class="example" %}

content/forms/labels.md

@@ -38,7 +38,7 @@ wcag_techniques:
   - ARIA16
 
 metafooter: true
-last_updated: 2019-07-27
+last_updated: 2024-05-13
 editors:
   - Eric Eggert: "https://www.w3.org/People/yatil/"
   - Shadi Abou-Zahra: "https://www.w3.org/People/shadi/"
@@ -305,3 +305,10 @@ If the image button (`<input type="image">`) is used, the label is set in the `a
 In left-to-right languages, it is customary to visually position labels to the right of radio buttons and checkboxes, and to the left or directly above other form fields. Maintaining this practice increases predictability and understandability of your form for all users.
 
 In general, placing labels above the form fields helps reduce horizontal scrolling for people with low vision and mobile device users. However, the usefulness of this approach depends on other design aspects, such as the proximity of other nearby form fields and content, and needs to be assessed individually. The aim should be to maintain a close and distinct visual relationship between the label and the form control.
+
+
+## Form field controls for mobile
+When HTML5 form fields are used, a virtual keyboard appears making it easier to input data.
+For example, a `number` field shows a numeric keyboard, a `date` field a native date picker.
+
+Sometime designers propose not including visual field labels. However, most users prefer or even need visible labels to understand the form.

content/forms/multi-page.md

@@ -154,9 +154,11 @@ progress {
 }
 
 progress::-webkit-progress-bar {
-	background-color:#036;
+	background-color:#FFF;
+}
+progress::-webkit-progress-value {
+	background-color: #036;
 }
-
 progress::-moz-progress-bar {
 	background-color:#036;
 }
@@ -201,6 +203,9 @@ progress {
 
 /* Apple Safari and Google Chrome */
 progress::-webkit-progress-bar {
+	background-color: #FFF;
+}
+progress::-webkit-progress-value {
 	background-color: #036;
 }
 

content/images/decision-tree.md

@@ -5,7 +5,7 @@
 title: "An alt Decision Tree"
 title_html: "An <code>alt</code> Decision Tree"
 lang: en  # Change "en" to the translated-language shortcode
-last_updated: 2024-01-15  # Put the date of this translation YYYY-MM-DD (with month in the middle)
+last_updated: 2024-05-13  # Put the date of this translation YYYY-MM-DD (with month in the middle)
 
 # translators: # remove from the beginning of this line and the lines below: "# " (the hash sign and the space)
 # - name: "Translator Name Here" # Add one -name: line for every translator
@@ -87,5 +87,5 @@ This decision tree describes how to use the `alt` attribute of the `<img>` eleme
   - {:.no} **No:**
     - Continue.
 - **Is the image’s use not listed above or it’s unclear what `alt` text to provide?**
-  - {:.yes} This decision tree **does not** cover all cases. For detailed information on the provision of text alternatives refer to the [Image Concepts Page](/tutorials/images/).
-{:.decision-tree}
+  - {:.yes} This decision tree **does not** cover all cases. For detailed information on the provision of text alternatives refer to the [[Images Tutorials]](/tutorials/images/).
+{:.decision-tree}

content/images/index.md

@@ -14,6 +14,8 @@ metafooter: true
 
 resource:
   ref: /tutorials/
+  title: "Images Tutorials"
+
 navigation:
   next: /tutorials/images/informative/
 

content/menus/structure.md

@@ -23,7 +23,7 @@ wcag_techniques:
   - ARIA11
 
 metafooter: true
-last_updated: 2017-04-13
+last_updated: 2024-05-13
 editors:
   - Eric Eggert: "https://www.w3.org/People/yatil/"
   - Shadi Abou-Zahra: "https://www.w3.org/People/shadi/"
@@ -191,3 +191,6 @@ In the following example the link in the navigation points to the main content o
 {::nomarkdown}
 {% include box.html type="end" %}
 {:/}
+
+## Responsive design
+Menu structure should be consistent across screen sizes. Some menu items may be collapsed or even hidden in sub navigation menus, but items that show should appear in the same order and with the same wording and destination.

content/page-structure/regions.md

@@ -29,7 +29,7 @@ wcag_techniques:
   - ARIA11
 
 metafooter: true
-last_updated: 2022-02-08
+last_updated: 2024-05-13
 editors:
 - Eric Eggert: "https://www.w3.org/People/yatil/"
 - Shadi Abou-Zahra: "https://www.w3.org/People/shadi/"
@@ -183,9 +183,12 @@ The [Menus tutorial](/tutorials/menus/) provides more details on creating menus.
 {% include box.html type="end" %}
 {:/}
 
+## Responsive design
+Components may be collapsed or even hidden on smaller screens, but components that show should appear in the same order for a particular view (set size and orientation). If possible, page structure should be consistent across different screen sizes and orientations, though not a specific WCAG requirement.
+
 {% include ednote.html note="Remove or drastically simplify the next two sections." status="proposed" %}
 
-## Page Regions in HTML5 Using WAI-ARIA
+## Page regions in HTML5 using WAI-ARIA
 {:#accessupport}
 
 Most current web browsers support the above HTML5 elements and convey the information to assistive technology through the accessibility APIs. However, to maximize compatibility with web browsers and assistive technologies that support WAI-ARIA but do not yet support HTML5, it is currently advisable to use both the HTML5 elements and the corresponding WAI-ARIA roles.
@@ -212,7 +215,7 @@ Explore other WAI-ARIA resources:
 * [WAI-ARIA Overview](https://www.w3.org/WAI/intro/aria)
 * [Notes on Using ARIA in HTML](https://www.w3.org/TR/aria-in-html/)
 
-## Page Regions in HTML4 Using WAI-ARIA
+## Page regions in HTML4 using WAI-ARIA
 {:#accessupport-html4}
 
 If HTML5 cannot be used or if an HTML4 page is retrofitted to improve accessibility, add WAI-ARIA code to `div` elements that function as their HTML5 counterparts, for example:

content/tables/multi-level.md

@@ -67,7 +67,7 @@ In the table below, the headers for the top half of the tables are different to
     Supplier contacts
   </caption>
   <tr>
-    <th id="blank">&nbsp;</th>
+    <td id="blank">&nbsp;</td>
     <th id="co1" headers="blank">Example 1 Ltd</th>
     <th id="co2" headers="blank">Example 2 Co</th>
   </tr>
@@ -87,7 +87,7 @@ In the table below, the headers for the top half of the tables are different to
     <td headers="co2 e1">marie@2co.example.com</td>
   </tr>
   <tr>
-    <th>&nbsp;</th>
+    <td>&nbsp;</td>
     <th id="co3" headers="blank">Example 3 Ltd</th>
     <th id="co4" headers="blank">Example 4 Inc</th>
   </tr>

content/tables/tips.md

@@ -17,7 +17,7 @@ navigation:
   previous: /tutorials/tables/caption-summary/
 
 metafooter: true
-last_updated: 2019-07-27
+last_updated: 2024-05-13
 editors:
   - Eric Eggert: "https://www.w3.org/People/yatil/"
   - Shadi Abou-Zahra: "https://www.w3.org/People/shadi/"
@@ -31,6 +31,8 @@ support: Developed by the Education and Outreach Working Group (<a href="https:/
 
 -   **Keep it simple:** Complex tables are more work for content creators as well as being harder to interpret for users. It’s usually better to [break up complex tables into simple individual tables](/tutorials/tables/multi-level/#split-up-multi-level-tables), each containing the data for one sub-topic.
 
+-   **Responsive design:** On small screens, in a small viewport, in zoomed views, with enlarged text, and other situations, responsive tables often change format. Ensure that the structural relationship is available in all formats.
+
 -   **Table separation:** If several tables follow one another, don’t use a single table and put in an additional row of `<th>` cells. Screen readers may read aloud all `<th>` cells in a column, resulting in confusion. [Start a new `<table>` when the topic changes.](/tutorials/tables/multi-level/#split-up-multi-level-tables)
 
 -   **Data separation:**