Re: Capabilities Draft Typographical Errors

Done! Awesome catches, Mike! Big thanks.

IMPORTANT:

Mike correctly suggested a rewrite of the first sentence in Sec 3. I
came up with:

"The capabilities discussed in this section facilitate content
re-rendering in order to render content with the specific presentational
characteristics each user finds most accommodative."

Please check in context:

https://a11yedge.github.io/capabilities/#present

This paragraph summarizes our argument that post-source does
accessibility in a way source simply can't so well, imo!

Best,
Janina

Mike Paciello writes:
> All -
> 
> Before I begin, can someone clarify whether the URL for the Latest Public
> Version is supposed to be functional? Right now, I get a 504 error when I
> click on it.
> 
> Here is my last set of recommended revisions starting at Section 2:
> 
> 1. *Section 2.2.3* - In the Automatability subsection, lowercase the "C" in
> the word "Cases" for document consistency.
> 2. *Section 3 *- Please review the opening introductory sentence. This
> phrase "in this section are afforded" in the sentence doesn't read
> grammatically correct to me: "The capabilities discussed in this section *are
> afforded users* to facilitate content re-rendering...". Perhaps revise as
> follows: "The capabilities discussed in this section *allow users* to
> facilitate content re-rendering..."
> 3. *Section 4.4.2* - In the subsection, "Benefit", the word "Support"
> should have a lowercase "s".
> 4. *Section 4.5.1* - In the subsection, "Trade-Offs", delete the double
> instance of the word "to" in the sentence, "There is no particular benefit
> to to performing this mediation post-source."
> 5. *Section 4.5.1 *- In the subsection, "Benefit" add the word "to"
> following the word, "provided" in the sentence, "users simply deserve the
> best structural semantics that can be provided them in the moment..."
> 6. *Section 6.5* - This section is titled, "Accessibility Statement
> Discover Ability". Isn't the word supposed to be "Discoverability"?
> Additionally, within the introductory paragraph the acronym "Accessible
> platform Architectures (APA)", initial cap the word, "platform".
> 
> -Mike
> 
> Mike Paciello
> Chief Accessibility Officer
> michael.paciello@audioeye.com
> +1.603.484.1938
> 
> [image: AudioEye Registered Trademark Logo]
> [image: Follow us on LinkedIn for more accessibility tips!]
> <https://www.linkedin.com/company/audioeye-inc/>
> 
> 
> On Thu, Oct 23, 2025 at 5:29???PM Michael Paciello <
> michael.paciello@audioeye.com> wrote:
> 
> > All -
> >
> > Following is an *initial* list of typographical errors I've identified in
> > the current Capabilities draft document:
> >
> > 1. *Abstract* - remove period after the word "capabilities"
> > 2. *Section 1.2* - In the paragraph under the Note, remove the period
> > after the word "methods"
> > 3. *Section 1.3* - The spacing in the fourth bulleted item "Does Not
> > Apply" and the hyphen that follows the phrase is different from the spacing
> > for the 3 previous bulleted items. Is this a code or formatting error?
> > 4. *Section 4.4.2* - Under the subsection "Trade-Offs", initial cap the
> > first word, "post source"
> > 5. *Section 4.4.6* - Under the subsection "Benefit", remove the extra
> > space between the period and the end of the sentence.
> > 6. *Section 6.2.2* - Under the subsection "Benefit", remove the comma at
> > the end of the sentence ending with the word "proximate" and before the
> > period.
> > 7. *Appendix B.1* - Initial-cap the word. "third-party" at the beginning
> > of the paragraph.
> >
> > I am completely reviewing the entire document again (my last time, I
> > promise!). I just started Section 2 and expect to finish this evening at
> > some point.
> >
> > Additionally, while I know we've had this discussion before, I do wonder
> > whether we should include a brief description, acknowledgement and link to
> > the Overlay Fact Sheet within Section 1.4 of our draft? It clearly is NOT a
> > regulatory ruling, though I am pretty sure I have seen it referenced in
> > some US State regulatory standards (Colorado OIT?). I've also recently
> > noticed that the document has gained new traction, likely as a result of
> > recent conferences where the topic of Overlays is still popular (i.e.,
> > M-Enabling, A11yTO). Additionally, Section 1.4 is not limited to regulatory
> > rulings; it's just that the introductory paragraph cites those regulatory
> > references.
> >
> > Again, it's likely too late to make this, but as I think about it, I
> > believe doing so at least suggests that our research is objective, without
> > any technical prejudice. A single sentence acknowledging the work with a
> > link would suffice. However, I will support the decision of the group,
> > especially this is very late in the publication process.
> >
> > -Mike
> >
> > Mike Paciello
> > Chief Accessibility Officer
> > michael.paciello@audioeye.com
> > +1.603.484.1938
> >
> > [image: AudioEye Registered Trademark Logo]
> > [image: Follow us on LinkedIn for more accessibility tips!]
> > <https://www.linkedin.com/company/audioeye-inc/>
> >
> 
> -- 
> The information in this communication is intended for the use of the 
> individual or entity to which it is addressed, and may contain information 
> that is PRIVILEGED, CONFIDENTIAL and/or exempt from disclosure under law. 
> If you are not the intended recipient, you are hereby notified that any 
> dissemination, distribution or copying of this communication is strictly 
> prohibited.

-- 

Janina Sajka (she/her/hers)
Accessibility Consultant https://linkedin.com/in/jsajka

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Co-Chair, Accessible Platform Architectures	http://www.w3.org/wai/apa

Linux Foundation Fellow
https://www.linuxfoundation.org/board-of-directors-2/

Received on Friday, 24 October 2025 13:18:06 UTC