Fix some typos, grammar issues, and links (#525)

Accessibility/CaretBrowsing/designDoc.md

@@ -48,7 +48,7 @@ The kCaretBrowsingEnabled preference is registered with a [PrefChangeRegistrar](
 
 The confirmation dialog that is shown when you press F7 is implemented by a new CaretBrowsingDialogDelegate class. The class inherits from a [DialogDelegateView](https://cs.chromium.org/chromium/src/ui/views/window/dialog_delegate.h?sq=package:chromium&g=0&l=178) class and overrides the methods it needs in order to provide the correct strings and functionality. The strings for the dialog are defined in [generated_resources.grd](https://cs.chromium.org/chromium/src/chrome/app/generated_resources.grd?q=generated_resources.grd&dr). A ShowCaretBrowsingDialog method is added to the [BrowserWindow](https://cs.chromium.org/chromium/src/chrome/browser/ui/browser_window.h?type=cs&q=+BrowserWindow&g=0&l=100) interface, which is implemented by [BrowserView](https://cs.chromium.org/chromium/src/chrome/browser/ui/views/frame/browser_view.h?type=cs&q=BrowserView&g=0&l=99). This method calls a static method of CaretBrowsingDialogDelegate to show the dialog. (A stub implementation of ShowCaretBrowsingDialog is also added to [TestBrowserWindow](https://cs.chromium.org/chromium/src/chrome/test/base/test_browser_window.h?type=cs&q=TestBrowserWindow&g=0&l=36).)
 
-### The caret browsing experimental feature flag chrome://flags)
+### The caret browsing experimental feature flag (chrome://flags)
 
 There is a "caret-browsing" experimental feature flag that determines if pressing F7 is ignored by the browser or if F7 starts the "toggle caret browsing mode" flow.
 

Accessibility/CaretBrowsing/explainer.md

@@ -7,7 +7,7 @@ Sample caret browsing experience in Microsoft Edge on Wikipedia:
 ![Visual sample of using caret browsing to explore Wikipedia front page](CB_Example.gif)
 
 ### Current problems:
-Today Chromium users can download Caret Browsing extension from the Chrome Web Store. The are two problems with this approach:
+Today Chromium users can download Caret Browsing extension from the Chrome Web Store. There are two problems with this approach:
 
 * Extensions might be blocked in a work environment due to enterprise policies. See [Issue 611798] (https://crbug.com/611798);
 * Extensions might not be available in "Incognito" tabs, or when Guest profile is used;
@@ -27,7 +27,7 @@ Native caret browsing doesn't aim to replace extensions, they would continue to
 ## Solution:
 The solution proposed in this explainer is to introduce native caret browsing in Chromium, a feature that is available in Mozilla Firefox, Microsoft Edge and Internet Explorer.
 
-In order to do that we suggest to implement a current common activation shortcut: F7 and confirm caret browsing activation with a dialog.
+In order to do that we suggest implementing a current common activation shortcut: F7 and confirm caret browsing activation with a dialog.
 
 Caret browsing activation confirmation in Microsoft Edge:
 ![Microsoft Edge browser dialog that asks user to confirm enabling caret browsing and allow to set the preference to never ask again in the future](edgeCaretBrosingPrompt.png)

Accessibility/ConfirmationOfAction/explainer.md

@@ -54,10 +54,10 @@ pre-existing issues with the feature make it a challenge to use effectively:
   getting a more uniform experience.
 
 * Multiple live regions in use at a time introduce timing and precedence concerns
-  for which content authors have limited control (e.g., `polite` and `assertive`
+  for which content authors have limited control (e.g., `polite` and `assertive`)
   set basic expectations around precedence of announcements, but offer little
   in the way of expressing timing (apart from the moment the change is made), or 
-  other controlling factors like interruptability.
+  other controlling factors like interruptibility.
 
 * Live regions are built around the assumption that a _visual_ change needs to be
   announced, hence they are tightly coupled with DOM nodes. Many changes important
@@ -66,7 +66,7 @@ pre-existing issues with the feature make it a challenge to use effectively:
   these cases there is no surrounding context (an important consideration for many
   screen readers), nor any presentation to show. Worse yet, since these "live region
   hacks" do not play a role in the normal presentation flow of the content, they 
-  are usually ommitted for performance reasons until it is determined that a 
+  are usually omitted for performance reasons until it is determined that a 
   particular user needs an "accessible version" of the site (or by heuristically 
   trying to detect this--which is not a recommended practice). Accessibility should
   be designed into the experience from the start, and not bolted-on as an extra or
@@ -186,7 +186,7 @@ document.ariaNotify( "Text copied to clipboard.", { label: "clipboard" } );
 ```
 
 The label is used to group or categorize similar notifications. Assistive technology may
-chose to use these labels to provide a filtering mechanism for users.
+choose to use these labels to provide a filtering mechanism for users.
 
 Other means of expressing priority and coalescing behavior for similarly-labelled 
 notifications may be defined.
@@ -214,7 +214,7 @@ of platforms and assistive technologies on the web.
 #### Only plain text as input?
 
 Should the API allow for richer formatted text? Formatted text could provide hints 
-for expressiveness and pronounciation (TTML and WebVTT are potential candidates).
+for expressiveness and pronunciation (TTML and WebVTT are potential candidates).
 
 What about supporting non-textual cues? We think other platform capabilities (like 
 `<audio>.play()`) can be used to handle non-textual output, and that non-textual
@@ -242,7 +242,7 @@ languages).
 
 #### Catering to verbosity preferences?
 
-It may useful to enable authors to offer multiple levels of verbosity for a
+It may be useful to enable authors to offer multiple levels of verbosity for a
 notification depending on how a user has configured their AT. For example, if ATs
 are configured for minimal output, perhaps a single word could additionally be
 provided that generalizes the full text of the notification.
@@ -275,7 +275,7 @@ avoid the risk of denial-of-service type attacks on ATs through this API.
 
 1. **Readback.** Any readback of configuration settings for an AT via an API have the
     potential of exposing a connected (vs. not connected) AT, and as such is an easy
-    target for fingerprinting AT users, an undesireable outcome. Similarly, confirmation
+    target for fingerprinting AT users, an undesirable outcome. Similarly, confirmation
     of notifications (such as via a fulfilled promise) have similar traits and are
     avoided in this proposal.
 2. **Authoritative-sounding notifications.** Announcements could be crafted to deceive

Accessibility/PrefersContrast/explainer.md

@@ -44,7 +44,7 @@ Similarly, on Windows, if High Contrast is not enabled, we match `(prefers-contr
 
 ## Design considerations 
 
-`prefers-contrast` had initially been designed to support three values: `high`, `low`, and `no-preference`. However, these values [failed to properly capture Increased Contrast Mode](https://github.com/w3c/csswg-drafts/issues/2943) on macOS and iOS. More specifically, Increased Contrast is different from Window’s High Contrast Mode in that the result is not a true “high” contrast, but an intermediary “increased” contrast state. To encompass the varying OS settings, the values of `high` and `low` were update to a more general `more` and `less`. 
+`prefers-contrast` had initially been designed to support three values: `high`, `low`, and `no-preference`. However, these values [failed to properly capture Increased Contrast Mode](https://github.com/w3c/csswg-drafts/issues/2943) on macOS and iOS. More specifically, Increased Contrast is different from Window’s High Contrast Mode in that the result is not a true “high” contrast, but an intermediary “increased” contrast state. To encompass the varying OS settings, the values of `high` and `low` were updated to a more general `more` and `less`. 
 
 This three-value design, however, was flagged as potentially problematic for Forced Colors Mode users that have a color scheme with contrast ratios which are not considered particularly high or low. More specifically, if an author were to apply styles using the `prefers-contrast` boolean context to, for example, reduce visual complexity for all users with a contrast preference, any user whose Forced Color Scheme did not match `more` or `less` would fail to see these updated styles. 
 

CSSAnchoredPositioning/explainer.md

@@ -514,7 +514,7 @@ First, properties affecting the inline direction of the margin box would be adju
 * `padding-left`, `padding-right`, `padding-inline-start`, `padding-inline-end`
 * `border-left`, `border-right`, `border-inline-start`, `border-inline-end`
 
-In the example above, the first set of author-specified properties having an affect on the inline margin box size would be:
+In the example above, the first set of author-specified properties having an effect on the inline margin box size would be:
 
 ```css
     #my-popup {
@@ -615,7 +615,7 @@ A conceivable alternative is to impose restrictions on which elements can serve
 
 ### Should the user agent provide a default repositioning scheme?
 
-Such an algorithm would need to be predictible, straightforward to implement for interoperability, and simple to understand in lay terms. As an example, UAs could mirror edge positions (e.g. a popup's top-left corner pinned to the anchor's bottom-left => top-right corner pinned to bottom-right) and nudge center positions (e.g. a popup with its top-center pinned will be nudged just enough pixels horizontally in order to stay in the viewport). Should authors need to a lightweight opt-in for default repositioning logic?
+Such an algorithm would need to be predictable, straightforward to implement for interoperability, and simple to understand in lay terms. As an example, UAs could mirror edge positions (e.g. a popup's top-left corner pinned to the anchor's bottom-left => top-right corner pinned to bottom-right) and nudge center positions (e.g. a popup with its top-center pinned will be nudged just enough pixels horizontally in order to stay in the viewport). Should authors need to a lightweight opt-in for default repositioning logic?
 
 ### How could we better support directionally-aware styles?
 

CSSColorMix/explainer.md

@@ -26,7 +26,7 @@ and blue, can have the same HSL lightness).
 ## Use Cases
 
 One example application of `color-mix()` is tinting. The css-color-5 spec also proposes `color-adjust()`, which can adjust the lightness of a color up or down. This is
-analagous to adjusting the tint of a paint color by mixing it with a pure white or pure black paint. The `color-mix()` function provides greater flexibility, by allowing for
+analogous to adjusting the tint of a paint color by mixing it with a pure white or pure black paint. The `color-mix()` function provides greater flexibility, by allowing for
 adjustment using colors other than pure white or pure black. Doing so can provide "warmth" or "coolness" to a color palette, as seen in
 [this example](https://alistapart.com/article/mixing-color-for-the-web-with-sass/#section5) using Sass.
 

CSSModules/v1Explainer.md

@@ -36,7 +36,7 @@ The default export of the module is the CSSStyleSheet generated from the CSS fil
 
 ## Some implementation details
 
-The MIME-type in the HTTP response header is checked to determine how a given module should interpreted.  A MIME-type of `text/css` will be treated as a CSS module.  Each imported CSS Module will have its own [module record](https://tc39.github.io/ecma262/#sec-abstract-module-records) as introduced in the ES6 spec and will participate in the module map and module dependency graphs.
+The MIME-type in the HTTP response header is checked to determine how a given module should be interpreted.  A MIME-type of `text/css` will be treated as a CSS module.  Each imported CSS Module will have its own [module record](https://tc39.github.io/ecma262/#sec-abstract-module-records) as introduced in the ES6 spec and will participate in the module map and module dependency graphs.
 
 The V1 of CSS Modules will be built using Synthetic Modules.  Specifically, to create a new CSS module given a fetched `text/css` file:
 1. Create a CSSStyleSheet() via the [constructor](https://wicg.github.io/construct-stylesheets/#dom-cssstylesheet-cssstylesheet).

Canvas/FormattedText.md

@@ -188,7 +188,7 @@ content that changed.
 
 To render one line at a time, we need to introduce a few additional objects and concepts.
 First of all, we need to be able to indicate what portion of the aggregate `CanvasFormattedText`
-text runs we need to render on each separate line, and we need to be able to specify a maxium
+text runs we need to render on each separate line, and we need to be able to specify a maximum
 width to render them into (which can change from line to line). The API is designed to allow
 an iterative approach to line rendering, but is also flexible enough to allow for many other
 scenarios.
@@ -205,7 +205,7 @@ components:
     position object belongs.
 2. `textRunIndex` - required number - the index of a text run object contained by the
     `CanvasFormattedText` (e.g., the object associated with the text run "the quick " in
-    the example above.
+    the example above).
 3. `textRunOffset` - required number - the offset into the text run value itself. For example:
     a `2` would indicate a position starting at the "e" in the string "the quick".
 
@@ -254,7 +254,7 @@ while ( startPosition ) {
 }
 ```
 
-We can use this additional flexibility to adjust each line's width and position to accomodate
+We can use this additional flexibility to adjust each line's width and position to accommodate
 any other objects being presented to the canvas. In this example, we adjust the lines to wrap
 around an image.
 
@@ -448,7 +448,7 @@ redraw the same text content for a changing available width.
 
 ## Accessibility Considerations
 
-Making the Canvas accessible is a persistant challenge for the web today. Several
+Making the Canvas accessible is a persistent challenge for the web today. Several
 efforts are underway, including a
 [promising solution](https://github.com/WICG/aom/blob/gh-pages/explainer.md#use-case-4-adding-non-dom-nodes-virtual-nodes-to-the-accessibility-tree)
 as part of the Accessible Object Model (AOM) family of proposals.

ClipboardPickle/tag-security-privacy.md

@@ -47,7 +47,7 @@ No.
 
 No.
 
-### 2.12. What temporary identifiers might this this specification create or expose to the web?
+### 2.12. What temporary identifiers might this specification create or expose to the web?
 
 None.