Re: New Diagram, Minutes

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/

Received on Friday, 31 January 2025 12:55:56 UTC