You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: files/en-us/learn_web_development/core/accessibility/test_your_skills/html/index.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -321,7 +321,7 @@ header {
321
321
322
322
The accessibility issues are:
323
323
324
-
1. The header image is decorative, so doesn't need alt text. The best solution if you are going to use decorative HTML images is to put `alt=""`, so a screenreader will just read out nothing — rather than a description, or the image file name. It is not part of the content.
324
+
1. The header image is decorative, so doesn't need alt text. The best solution if you are going to use decorative HTML images is to put `alt=""`, so a screen reader will just read out nothing — rather than a description, or the image file name. It is not part of the content.
325
325
2. The gallery images need alt text, and they are part of the content.
Copy file name to clipboardExpand all lines: files/en-us/learn_web_development/core/accessibility/test_your_skills/wai-aria/index.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -149,7 +149,7 @@ The problem we have now is that when the DOM changes to show a new description,
149
149
To complete the task:
150
150
151
151
1. Click **"Play"** in the code block below to edit the example in the MDN Playground.
152
-
2. Update the HTML so that the description updates are announced by the screenreader.
152
+
2. Update the HTML so that the description updates are announced by the screen reader.
153
153
154
154
> [!CALLOUT]
155
155
>
@@ -238,7 +238,7 @@ function handleSelection(e) {
238
238
239
239
There are two ways to solve the problem outlined in this task:
240
240
241
-
- Add an `aria-live=""` attribute to the animal-description `<div>` to turn it into a live region, so when its content changes, the updated content will be read out by a screenreader. The best value is probably `assertive`, which makes the screenreader read out the updated content as soon as it changed. `polite` means that the screenreader will wait until other descriptions have finished before it starts reading out the changed content.
242
-
- Add a `role="alert"` attribute to the animal-description `<div>`, to make it have alert box semantics. This has the same effect on the screenreader as setting `aria-live="assertive"` on it.
241
+
- Add an `aria-live=""` attribute to the animal-description `<div>` to turn it into a live region, so when its content changes, the updated content will be read out by a screen reader. The best value is probably `assertive`, which makes the screen reader read out the updated content as soon as it changed. `polite` means that the screen reader will wait until other descriptions have finished before it starts reading out the changed content.
242
+
- Add a `role="alert"` attribute to the animal-description `<div>`, to make it have alert box semantics. This has the same effect on the screen reader as setting `aria-live="assertive"` on it.
Copy file name to clipboardExpand all lines: files/en-us/mozilla/firefox/releases/141/index.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -95,7 +95,7 @@ Firefox 141 is the current [Beta version of Firefox](https://www.firefox.com/en-
95
95
96
96
#### Marionette
97
97
98
-
- To avoid unnecessary 200ms delays for each call to `WebDriver:ElementClick` - even when no navigation occurrs - we lowered the click-and-wait timeout for a potential navigation to 50ms for backward compatibility. The [timeout is now also configurable](https://firefox-source-docs.mozilla.org/testing/marionette/Prefs.html#marionette-navigate-after-click-timeout) and [can be completely disabled](https://firefox-source-docs.mozilla.org/testing/marionette/Prefs.html#marionette-navigate-after-click-enabled) by users through a preference ([Firefox bug 1972271](https://bugzil.la/1972271)).
98
+
- To avoid unnecessary 200ms delays for each call to `WebDriver:ElementClick` - even when no navigation occurs - we lowered the click-and-wait timeout for a potential navigation to 50ms for backward compatibility. The [timeout is now also configurable](https://firefox-source-docs.mozilla.org/testing/marionette/Prefs.html#marionette-navigate-after-click-timeout) and [can be completely disabled](https://firefox-source-docs.mozilla.org/testing/marionette/Prefs.html#marionette-navigate-after-click-enabled) by users through a preference ([Firefox bug 1972271](https://bugzil.la/1972271)).
99
99
- Added support in Marionette for interacting with CHIPS cookies (Cookies Having Independent Partitioned State) ([Firefox bug 1972830](https://bugzil.la/1972830)).
Copy file name to clipboardExpand all lines: files/en-us/web/api/screen_capture_api/captured_surface_control/index.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -87,7 +87,7 @@ Finally, we include a {{htmlelement("video")}} element to display the captured d
87
87
88
88
## App CSS
89
89
90
-
The app CSS is minimal; it is worth noting that we have given the `<video>` a {{cssxref("max-width")}} of `100%`, so that it is constrained inside the `<body>`. The `<video>` could grow dramatically when the captured display surface is embedded inside it (its size is the capture's intrisic size), which could cause overflow issues if we didn't constrain it.
90
+
The app CSS is minimal; it is worth noting that we have given the `<video>` a {{cssxref("max-width")}} of `100%`, so that it is constrained inside the `<body>`. The `<video>` could grow dramatically when the captured display surface is embedded inside it (its size is the capture's intrinsic size), which could cause overflow issues if we didn't constrain it.
The `startCapture()` function, which starts screen capture, looks like so. We first create a new `CaptureController`, and pass it into our [`MediaDisplayOptions`](/en-US/docs/Web/API/MediaDevices/getDisplayMedia#options) object, along with a [`displaysurface`](/en-US/docs/Web/API/MediaTrackConstraints/displaySurface) constraint that causes the app to recommend sharing browser tabs.
145
+
The `startCapture()` function, which starts screen capture, looks like so. We first create a new `CaptureController`, and pass it into our [`MediaDisplayOptions`](/en-US/docs/Web/API/MediaDevices/getDisplayMedia#options) object, along with a [`displaySurface`](/en-US/docs/Web/API/MediaTrackConstraints/displaySurface) constraint that causes the app to recommend sharing browser tabs.
146
146
147
147
Now it's time to capture our media; we do so using a {{domxref("MediaDevices.getDisplayMedia()")}} call, to which we pass our options, and set the resulting promise as the value of the `<video>` element's {{domxref("HTMLMediaElement.srcObject", "srcObject")}} property. When it resolves, we continue the function by calling {{domxref("CaptureController.resetZoomLevel()")}} and setting the `<output>` element's contents to `100%`. This is not strictly necessary, but it can be a bit confusing when you capture a tab to find it is already zoomed out or in. Setting the zoom level to `100%` on capture feels a bit more logical. These lines of code deal with the case where the app is refreshed without pressing "Stop Capture", then capture is started again.
148
148
149
149
Our next step is to call {{domxref("CaptureController.getSupportedZoomLevels()")}} to retrieve the zoom levels the captured display surface supports, and store the resulting array in the `zoomLevels` variable.
150
150
151
-
Next, we use the controller's {{domxref("CaptureController.zoomlevelchange_event", "zoomlevelchange")}} event to detect when the zoom level is changed, print the current {{domxref("CaptureController.zoomlevel", "zoomlevel")}} to the `<output>` element, and call the user-defined `updateZoomButtonState()` function. This function will query the `zoomLevels` array to check whether the user can zoom in or out any further after each zoom change. We'll explain `updateZoomButtonState()` later on.
151
+
Next, we use the controller's {{domxref("CaptureController.zoomlevelchange_event", "zoomlevelchange")}} event to detect when the zoom level is changed, print the current {{domxref("CaptureController.zoomLevel", "zoomLevel")}} to the `<output>` element, and call the user-defined `updateZoomButtonState()` function. This function will query the `zoomLevels` array to check whether the user can zoom in or out any further after each zoom change. We'll explain `updateZoomButtonState()` later on.
152
152
153
153
We next unhide our zoom controls with `display: block`, enable our stop button, and disable our start button, so that the state of the controls makes sense after capture has bene started.
0 commit comments