Re: New Diagram, Minutes

Hi Jason:

Jason Taylor writes:
> Hi Janina
> 
> I feel the diagram is fine. And the general three steps are useful. With the middle step showing potential for multiple services adding benefit.
> 
I'm a bit confused. Are you saying you prefer the older diagram and not
this new candidate one?

The reason I pushed for a change is that B in the old diagram is deeply
unclear about providence. Fine, all these things can be done -- By whom?
That's the clarity I find missing in the old diagram.

PS: We're not tied to WCAG's scope. For us WCAG is a useful reference,
but not a scoping determinant.

Best,
Janina

> In summary.
> 
> 1. There is source code.
> 
> 2. The owner of that can add trusted services to help calling a rd party. there is the end user. They also could decide to add and use trusted services. Could be image to text services, browser extension.
> 
> 3. Then all that is rendered by the browser. That???s the final end user experience.
> 
> AT is after the browser , using the A11y tree or DOM, etc and I feel it???s beyond the scope. WCAG ends at the browser.
> 
> I hope clarifies.
> 
> J
> 
> 
> 
> 
> This e-mail and any accompanying attachments are intended only to be read or used by the named addressee(s). It is confidential and contains legally privileged information. If you have received this message in error, please notify the sender immediately and delete this message.
> 
> Sent from my iPhone
> 
> On Jan 31, 2025, at 7:55???AM, janina@rednote.net wrote:
> 
> ???Thanks, Jason. I agree that the user has ultimate authority over
> processing the content that is delivered over TCP/IP.
> 
> My concern that's resulted in rethinking our graphic is to clarify who
> provides what. I think it's quite possible, in fact fairly common that
> some transformations might be available from the content publisher's
> site or via browser plugins and/or AT of some kind.
> 
> 
> So, I'm agreeing with your point but don't understand how that
> invalidates the new graphic. Are you suggesting it does? Or that this
> duplication needs to be documented?
> 
> Earlier versions of Capabilities were actually organized around
> responsibility--what was the content publisher's responsibility, what
> the users. We also noted overlaps. We lost this clarity when later we
> deemed it useful to reorganize Capabilities around underlying
> technologies/features, html, css, js,.
> 
> Some of this old analysis remains, e.g. "Tradeoffs" at:
> 
> https://a11yedge.github.io/capabilities/#color
> 
> Best,
> Janina
> 
> 
> 
> 
> Jason Taylor writes:
> Hi
> 
> I know your intent to indicate that post source is up to the owner of the site to authorize. But I am not sure that is how Browser extensions work.
> 
> As a user I could have a browser extension that provides alt tags to images. I don???t see why the user would need authority.
> 
> Just my first read reaction.
> 
> J
> 
> 
> This e-mail and any accompanying attachments are intended only to be read or used by the named addressee(s). It is confidential and contains legally privileged information. If you have received this message in error, please notify the sender immediately and delete this message.
> 
> Sent from my iPhone
> 
> On Jan 30, 2025, at 1:59???PM, Lionel Wolberger <lionel.wolberger@levelaccess.com> wrote:
> 
> ???
> A fresh reading revealed to me an issue with the following:  ???The publisher has the sole authority to configure, or allow, any post-source adaptations to be called into play.???
> 
> While it may tax the reader, this is more accurate: ???The publisher has the sole authority to configure, or allow, any post-source adaptations that will be sent to the browser as part of the original page.???
> 
> This wording allows for browser extensions, CDN interventions, and other post-source happenstances that are not in any way expected or authorized by source.
> 
> 
> 
> From: Lionel Wolberger <lionel.wolberger@levelaccess.com>
> Date: Wednesday, January 29, 2025 at 23:40
> To: Jason Taylor <jason@usablenet.com>
> Cc: Accessibility at the Edge <public-a11yedge@w3.org>
> Subject: Re: New Diagram, Minutes
> We should also stipulate, A, B, C is for illustrative purposes: there could be 1 or 100 of such post-source additions to the mash-up.
> 
> Not clear your suggestion re: client.
> 
> I expect Janina will adjust the language anyway.
> 
> From: Jason Taylor <jason@usablenet.com>
> Date: Wednesday, January 29, 2025 at 23:29
> To: Lionel Wolberger <lionel.wolberger@levelaccess.com>
> Cc: Accessibility at the Edge <public-a11yedge@w3.org>
> Subject: Re: New Diagram, Minutes
> Agree with less is more.
> 
> You may want to address / adjust the word ???client??? in step 3.
> 
> 
> This e-mail and any accompanying attachments are intended only to be read or used by the named addressee(s). It is confidential and contains legally privileged information. If you have received this message in error, please notify the sender immediately and delete this message.
> 
> Sent from my iPhone
> 
> On Jan 29, 2025, at 4:26???PM, Lionel Wolberger <lionel.wolberger@levelaccess.com> wrote:
> ???
> We could leave out examples of 2 entirely ??? it is the entire document after all.
> 
> Revised:
> 
> The diagram represents a model where post-source adaptations enhance accessibility beyond the original content provided by the publisher. Here???s a breakdown of its structure:
> 1. Content Publisher (Content/Code) ??? At the top is the starting point, where the original web content or code is created by the publisher. The publisher has the sole authority to configure, or allow, any post-source adaptations to be called into play.
> 2. Post-Source A, B, C ??? These represent various post-source accessibility modifications or enhancements that occur after the content is published. Such adaptations are enumerated in the document.
> 3. Client User???s Tools (e.g., Browser, AT) ??? This is the endpoint where the content is consumed by the user. The client cannot easily distinguish the provenance of all the content and adaptations, which are processed equally for rendering by the end-user???s user agent and its ecosystem. Assistive technologies (AT), such as screen readers, browsers, or other user-side tools, integrate the post-source modifications for improved accessibility, and are consumed on the end user???s devices.
> 
> The diagram visually conveys the concept that accessibility is not solely dependent on the content publisher but can be enhanced through external post-source mechanisms before reaching the user. Let me know if you need a refined version or additional context!
> 
> 
> From: Jason Taylor <jason@usablenet.com>
> Date: Wednesday, January 29, 2025 at 23:14
> To: Lionel Wolberger <lionel.wolberger@levelaccess.com>
> Cc: Accessibility at the Edge <public-a11yedge@w3.org>
> Subject: Re: New Diagram, Minutes
> Hi All
> 
> I would suggest 2. b is a little simplistic if this represents how the majority of overlays update the DOM and the CSS?
> 
> J
> 
> 
> 
> 
> This e-mail and any accompanying attachments are intended only to be read or used by the named addressee(s). It is confidential and contains legally privileged information. If you have received this message in error, please notify the sender immediately and delete this message.
> 
> Sent from my iPhone
> 
> On Jan 29, 2025, at 3:57???PM, Lionel Wolberger <lionel.wolberger@levelaccess.com> wrote:
> ???
> Dear Community Group,
> 
> We revised the diagram based on today???s discussion.
> The diagram is attached here and described below.
> 
> <image001.png>
> 
> The diagram represents a model where post-source adaptations enhance accessibility beyond the original content provided by the publisher. Here???s a breakdown of its structure:
> 1. Content Publisher (Content/Code) ??? At the top is the starting point, where the original web content or code is created by the publisher. The publisher has the sole authority to configure, or allow, any post-source adaptations to be called into play.
> 2. Post-Source A, B, C ??? These represent various post-source accessibility modifications or enhancements that occur after the content is published. Examples include (a) Automated or third-party-generated captions for videos (b) image alternative texts (c) personalization widgets and many other adaptations described in the document.
> 3. Client User???s Tools (e.g., Browser, AT) ??? This is the endpoint where the content is consumed by the user. The client cannot easily distinguish the provenance of all the content and adaptations, which are processed equally for rendering by the end-user???s user agent and its ecosystem. Assistive technologies (AT), such as screen readers, browsers, or other user-side tools, integrate the post-source modifications for improved accessibility, and are consumed on the end user???s devices.
> 
> The diagram visually conveys the concept that accessibility is not solely dependent on the content publisher but can be enhanced through external post-source mechanisms before reaching the user. Let me know if you need a refined version or additional context!
> 
> 
> The minutes can be found here, https://www.w3.org/2025/01/29-a11yedge-minutes.html
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> Lionel Wolberger
> CCOO UserWay, A Level Access Company
> 
> 
> --
> 
> 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/
> 

-- 

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, 31 January 2025 13:55:25 UTC