Revise/ Clarify definition of an overlay?

[karlgroves]

I am raising this issue and asking for comments in response to the discussion around this PR

One thing I hope we can remain focused on is that the Overlay Factsheet is not intended to discuss the capabilities (or lack thereof) of any specific tool or tools. So, the explicit inclusion of any product is based solely on the extent to which the (loosely worded) description of an overlay applies to the product.

The definition is described in What is a web accessibility overlay?

In itemized fashion, here's my breakdown of how to identify an overlay:

1. Is a third-party product
2. Is intended to fix accessibility issues on a page

Additionally, the Fact Sheet also discusses the pseudo-assistive technology widgets like those from accessiBe, EqualWeb, UserWay, User1st, et al.

However, the provision of a widget is not in the definition. That fact has resulted in a handful of complaints of hypocrisy for not including Alchemy, Sentinel, and Amaze. In fact, the fact sheet explicitly says that the statement exempts those products. As a result, I now see the point and agree with the hypocrisy allegation. Strictly speaking, the definition of an overlay does apply to Alchemy, Sentinel, and Amaze (and Usablenet's Assistive, the topic of PR 932).

The initial argument against including Alchemy, Sentinel, and Amaze was as follows:

An additional class of product exists, which only perform automated repairs and are marketed as a temporary solution. These include Amaze by Deque Systems, Alchemy by Level Access, and Sentinel by Tenon.

For purposes of this document, these products aren't considered to be in the same class of product as the overlays that provide widgets. The most notable difference, beyond the lack of a “widget” is that Amaze, Alchemy, and Sentinel are understood by their manufacturers as being intended for use as an interim solution.

In other words, there are (were?) two reason why those products were not included

1. They have no "widget"
2. They avoid making false claims during their sales and marketing.

Possible Resolutions

Revise the definition to include the presence of a "widget"

This approach tends to align rather well with the content elsewhere in the document, but does not address the idea that those products without a widget are still not fully useful in attaining accessibility.

Put another way: a third-party product of any kind cannot deliver full accessibility on its own. The presence (or lack thereof) of a widget is inconsequential to this fact.

Maintain the definition as-is and include Alchemy, Sentinel, and Amaze

This approach resolves the controversy in PR 932 and also eliminates the inherent hypocrisy of not including Alchemy, Sentinel, and Amaze.

My personal preference is to take the latter approach, while also making minor tweaks for adding clarity.

Please comment!!!!

[karlgroves]

One additional note: IMO the allegations of false claims against any specific vendor are not relevant to the inclusion/ exclusion of any product. The Overlay False Claims resource handles that.

[UsableNet-WCAG]

I would add to this discussion the lack of any positive attributes to these approaches. There is a “strengths and weeknesses” section that lists one strength .

the fact sheet has tried to tarnish all with the same brush and a very negative brush. Many do deserve that brush but not all.

Some widgets for example don’t claim to fix any code , just add a widget. I don’t think these are very useful but they don’t make false claims.

so information needs to be broader , needs to identify when solutions can solve real world challenges.

[aardrian]

Quick ideas:

1. Bureau of Internet Accessibility (now owned by AudioEye) provides a simplified definition within the title of its post If Your Accessibility Solution Can be Turned On and Off, You've Still Got an Accessibility Problem. Being able to turn off (or having the remediation fail to "turn on") may be a handy referential idea. AudioEye would be an overlay by its own definition.

2. In my Overlays Underwhelm talk I say, "A tool that provides some sort of accessibility or usability feature that may not be built into the underlying site; sometimes it replicates native features and sometimes it offers some other affordance."

3. A more off-the-cuff definition I offered on Twitter: "Anything requiring me to use CPU cycles on my computer while self-identifying a disability to un-break a site is an overlay to me. It is not an equal experience. […] a false choice between privacy/security and accessibility."

[UsableNet-WCAG]

Quick feedback

Quick snappy one lines help no one.

The world “tool” is misleading and not correct for most overlays - level access’s and Deque. A widget is a tool

Overlay do not , by technical default, have to be turned on or off. Clients actually prefer to have that option.

Most of the current list are widgets that added the ability to update some code but only html elements - easy stuff to fix and find with scanning. They don’t update CSS or actual JavaScript or other code used for components - the JavaScript of nearly all lists say they use only calls for html element updates.

Any website or web code can be updated to complete WCAG standards using the approach but the level of how deep and what can be changed relies on the Quailty and knowledge of developers and if the platforms that apply the updates.

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 Apr 20, 2022, at 11:56 AM, Adrian Roselli @.***> wrote:



Quick ideas:

1. Bureau of Internet Accessibility (now owned by AudioEye) provides a simplified definition within the title of its post If Your Accessibility Solution Can be Turned On and Off, You've Still Got an Accessibility Problemhttps://www.boia.org/blog/if-your-accessibility-solution-can-be-turned-off-and-on-youve-got-an-accessibility-problem. Being able to turn off (or having the remediation fail to "turn on") may be a handy referential idea. AudioEye would be an overlay by its own definition.

2. In my Overlays Underwhelmhttps://adrianroselli.com/2022/03/overlays-underwhelm-a11y-nyc.html#Overview talk I say, "A tool that provides some sort of accessibility or usability feature that may not be built into the underlying site; sometimes it replicates native features and sometimes it offers some other affordance."

3. A more off-the-cuff definition I offered on Twitterhttps://twitter.com/aardrian/status/1490027402373836800: "Anything requiring me to use CPU cycles on my computer while self-identifying a disability to un-break a site is an overlay to me. It is not an equal experience. […] a false choice between privacy/security and accessibility."

— Reply to this email directly, view it on GitHubhttps://github.com/karlgroves/overlayfactsheet/issues/957#issuecomment-1104100433, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATXNQE3ASIW6IKBETOEBSULVGASLBANCNFSM5T4OOZUQ. You are receiving this because you commented.Message ID: @.***>

[KristinaEngland]

I am for the latter approach you recommended Karl - I think your original definition of What is a web accessibility overlay? is broad enough to encompass all three technologies noted above.

[Accudio]

This response is specifically addressing the question of hypocrisy in excluding some tools. My thoughts aren't clear on a potential change in the definition of an overlay, so will comment separately if at all.

I agree that the latter approach makes most sense to me—including Alchemy, Sentinel and Amaze. Although not originally raised by the linked PR, I don't think it makes sense to draw a distinction based on business practices over the tool itself.

Conceivably an overlay that markets itself as a 'magic fix' could potentially be an effective short-term mitigation whilst manual fixes are in-progress, and equally a company could use a interim tool like Amaze permanently without intending to fix anything. That is also saying nothing of a circumstance where a product begins to migrate across—or span—that area, adding further ambiguity.

Perhaps instead of the paragraphs explicitly excluding some products, it could be noted that some 'overlays' can provide effective short-term mitigation until full accessibility work can be shipped.

[AMHeckel]

I am strongly in favor of the "include them all" option--having the OFS cover all tools that fit this broad definition in a neutral way is truly helpful to people who are trying to learn about the benefits and limitations of the different options out there. Not drawing lines so that some products that do the same basic thing are excluded as being somehow different will also give more weight to the real distinctions that can be laid out in terms of poorly designed overlays that make accessibility worse and/or invade user privacy.

For the OFS, sticking to very clear, unarguable facts like "no overlays actually fix accessibility and usability problems, but instead mask them" makes the whole document come across as more objective. When I'm trying to point others to a really well laid-out explanation, that sense of objectivity is hugely important, especially if I'm trying to counter recommendations those people have gotten from someone else. This approach also allows us to avoid discarding the whole idea of automated supports, which can be helpful even with their limitations . . . overlays that also incorporate a scan to ID definite problems and highlight potential problems can be a really, really good thing for site owners who are just learning accessibility. It won't let them find everything, but it's a stepping stone that lets them get a sense of how much more there is to do. The key, as always, lies in not seeing the automated tool as a cure-all.

Thank you for having this discussion!

[AMHeckel]

An addendum: widgets need to be addressed somewhere, somehow, but they really are distinct from the main overlay functionality and we need to treat them as such. Untangling widgets from overlays would allow for more of the kind of user testing we need to figure out when widgets can be useful and for what user base; right now the way that widgets have been lumped in with overlays has made widgets as a concept seem "bad."

[UsableNet-WCAG]

I would agree that the opening broad statement on the fact sheet:

“Overlays are a broad term for technologies that aim to improve the accessibility of a website. They apply third-party source code (typically JavaScript) to make improvements to the front-end code of the website.”

Provides a definition for all mentions solutions so far to be included.

The question and observations, would like to add after reading the fact sheet is the proceeding detail on the current fact sheet is mostly aimed at negative aspects of the worst versions that do little to help.

This is similar to having a definition for Electric vehicle as “a people carrier with four wheels, powered by batteries “ and then list everything wrong with golf carts.

The detail is important. The range of what can be done is very broad.

[lonnyobrien]

Private sector companies are producing, promoting and profiting from an idea of what disability is without clear accountability for accessibility. There is already a term for this that could be applied instead of overlay and can support merging the overlay fact sheet and overlay false claims into one community resource. Disability Dongle [website] https://blog.castac.org/2022/04/disability-dongle/

On Wed., Apr. 20, 2022, 11:48 a.m. Karl Groves, @.***> wrote:

One additional note: The allegations of false claims against any specific vendor are not relevant to the inclusion/ exclusion of any product. The Overlay False Claims https://overlayfalseclaims.com/ resource handles that.

— Reply to this email directly, view it on GitHub https://github.com/karlgroves/overlayfactsheet/issues/957#issuecomment-1104089724, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACM4HNWVFYGTLBB4NM6I6TLVGARL5ANCNFSM5T4OOZUQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[stringyland]

I'm also in favour of the second option, to keep the existing definition and include tools that were previously excluded. I think it's clearer for everyone.

The fact that some tools are marketed differently, or have different ways of being used, is interesting but beside the point. The point is that an overlay attempts to fix problems at the browser level, rather than at the authoring level. And so it will always be limited in its capacity to make relevant and useful fixes, because it cannot make deep structural changes, or take context into account. It will always be a performance burden too. Some overlay products are open about this limitation, and some aren't, but the limitation is always an inherent part of the overlay method.

[crystalenka]

The point is that an overlay attempts to fix problems at the browser level, rather than at the authoring level.

This is exactly how I see it too. I think the second approach is best, and that it should include the other tools mentioned.

While the manual remediation via overlay is an interesting approach, the fact is that if the overlay was removed (or didn't load), the remediations would no longer apply.

How the tools are marketed and whether or not their remediations work are irrelevant to the definition, in my opinion.

[UsableNet-WCAG]

Crystal’s interpretation here is correct. It’s about updating client side code and not server side code.

Overlay is a method not a tool in itself. The current overlay fact sheet mixes up the “method of overlay “ definition (first paragraph) with other features of tools that deploy the method to different degrees.

Many of the widgets listed on the fact sheet, do not deploy overlay code at all . Some deploy overlay code generated by the tools automatic (or some claim AI) input such as accessibe.

Others have different level of deployment of the overlay code such as Audioeye , that mix a little of both the accessiBe model and , if you pay more , have some manual verification.

As this is a fact sheet it should try and cover the subject in detail and not use broad brush comments.

Regards

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 Apr 21, 2022, at 5:50 AM, Crystal Dionysopoulos @.***> wrote:



The point is that an overlay attempts to fix problems at the browser level, rather than at the authoring level.

This is exactly how I see it too. I think the second approach is best, and that it should include the other tools mentioned.

While the manual remediation via overlay is an interesting approach, the fact is that if the overlay was removed (or didn't load), the remediations would no longer apply.

How the tools are marketed and whether or not their remediations work are irrelevant to the definition, in my opinion.

— Reply to this email directly, view it on GitHubhttps://github.com/karlgroves/overlayfactsheet/issues/957#issuecomment-1104978010, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATXNQE7Y6VEHI6A6554HUZLVGEQENANCNFSM5T4OOZUQ. You are receiving this because you commented.Message ID: @.***>

[LJWatson]

I support @karlgroves preference for the latter option (incorporating Amaze et al in the definition), and think that @crystalenka's definition is a good way to describe such things.

The false claims made by some vendors could be addressed elsewhere in the factsheet with a "things to look out for" section or such perhaps, but that's another issue.

[crystalenka]

To clarify, @stringyland mentioned "fix problems at the browser level, rather than at the authoring level" - I just quoted and expanded on it, so I can't take credit for that definition.

I agree that the false claims and differences between the various automated or manual approaches should be expanded on as well.

[karlgroves]

Based on the comments here so far, I will modify the content of the fact sheet accordingly:

1. Revising the definition slightly to mention that most-but-not-all overlays include a "widget"
2. Include an explicit list of widgetless overlays: Deque's Amaze, Level Access's Alchemy, Tenon's Sentinel, and UsableNet's Assistive
3. Include a note (more revising existing content) that automated repair, be it from a widget or the widgetless products, are best regarded as a temporary measure deployed while better long-term solutions are created.

I'd like to also address a comment made by @UsableNet-WCAG:

the fact sheet has tried to tarnish all with the same brush and a very negative brush

Speaking purely for myself: the goal of the OFS has never been to "tarnish" any company or product. I am a strong advocate for a free market with sensible regulation. I believe strongly that all companies should succeed or fail based upon their own merits. The false marketing of overlays is - and has always been - my primary gripe. I am on record stating this many times on twitter, the a11y slack, and on webinars that are available for review at anytime on YouTube.

The OFS exists to provide factual information. It is managed in an open repository under an MIT License and the repository's README file describes the mechanisms for content revisions. Consequently, if there are things that should be revised, PRs are always welcome.

No company should feel slighted or singled out by the OFS, because it is purposefully broad in nature. If any company feels negatively singled out, they should follow the process that @UsableNet-WCAG has (kudos on that, BTW) and should also consider whether the content in the OFS is objectively true and applicable to them and pivot accordingly.

Let me finish up with another thing I've said many times: In my opinion, all technical solutions to improving Web Accessibility should be explored. As an industry and as a community, we should embrace and encourage new thinking on ways to improve accessibility.

The problem with overlays is not their quality or efficacy. The problem is that they are marketed as a panacea when the objective facts do not support those claims. As a result, website owners are left to believe claims that are untrue and make purchasing decisions based on these false claims. The carry-on effect of this is that inaccessibility persists.

If overlay vendors did not lie, I would not be as active in efforts like OFS.

[UsableNet-WCAG]

Hi Karl

What is needed here? I can help with proposed content . Let me know

Jason

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 Apr 21, 2022, at 11:29 AM, Karl Groves @.***> wrote:



Based on the comments here so far, I will modify the content of the fact sheet accordingly:

1. Revising the definition slightly to mention that most-but-not-all overlays include a "widget"
2. Include an explicit list of widgetless overlays: Deque's Amaze, Level Access's Alchemy, Tenon's Sentinel, and UsableNet's Assistive
3. Include a note (more revising existing content) that automated repair, be it from a widget or the widgetless products, are best regarded as a temporary measure deployed while better long-term solutions are created.

I'd like to also address a comment made by @UsableNet-WCAGhttps://github.com/UsableNet-WCAG:

the fact sheet has tried to tarnish all with the same brush and a very negative brush

Speaking purely for myself: the goal of the OFS has never been to "tarnish" any company or product. I am a strong advocate for a free market with sensible regulation. I believe strongly that all companies should succeed or fail based upon their own merits. The false marketing of overlays is - and has always been - my primary gripe. I am on record stating this many times on twitter, the a11y slack, and on webinars that are available for review at anytime on YouTube.

The OFS exists to provide factual information. It is managed in an open repository under an MIT License and the repository's README file describes the mechanisms for content revisions. Consequently, it there are things that should be revised, PRs are always welcome.

No company should feel slighted or singled out by the OFS, because it is purposefully broad in nature. If any company feels negatively singled out, they should follow the process that @UsableNet-WCAGhttps://github.com/UsableNet-WCAG has (kudos on that, BTW) and should also consider whether the content in the OFS is objectively true and applicable to them and pivot accordingly.

Let me finish up with another thing I've said many times: In my opinion, all technical solutions to improving Web Accessibility should be explored. As an industry and as a community, we should embrace and encourage new thinking on ways to improve accessibility.

The problem with overlays is not their quality or efficacy. The problem is that they are marketed as a panacea when the objective facts do not support those claims. As a result, website owners are left to believe claims that are untrue and make purchasing decisions based on these false claims. The carry-on effect of this is that inaccessibility persists.

If overlay vendors did not lie, I would not be as active in efforts like OFS.

— Reply to this email directly, view it on GitHubhttps://github.com/karlgroves/overlayfactsheet/issues/957#issuecomment-1105382579, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATXNQEYVPFISLVIG4T6ZQN3VGFX4TANCNFSM5T4OOZUQ. You are receiving this because you were mentioned.Message ID: @.***>

[UsableNet-WCAG]

This article by Gareth Ford Williams is more balanced and covers the subject in a different way and not just focused on the automated and AI claims. Looks a little deeper into when the updating of content from specialized service has its place.

https://uxdesign.cc/what-are-accessibility-overlays-good-for-718c6e2ef531

[UsableNet-WCAG]

Hi Karl , maybe I can help provide some input that adds onto your action above.

In summary you identified there are three groups of products that the factsheet may need to address or decide what is included.

1. Widget based solutions that promote limited or no need to update code - provide mostly a control panel that manipulates the CSS layer offering users features such as changing font size , etc. current overlay fact sheet invoice these but mixed in with item 2 below

2. solutions that promote automated or AI code updates do the majority of the work for you , offering some widget options but the core promotion is around the lower of AI and automation to solve accessibility issues. Overlay fact sheet cover these but mixed up with item 1 above and recently added UsableNet Assistive that fits into group 3 below.

3. solutions that provide update to code via a manual developer process . These are solutions that involve similar levels of development of accessibility remediation as needed if original code was updated. Includes manual testing, do not relay on automated solutions. This group is not covered in the overlay sheet. There are four solitons you identified. This includes the Tenon sentinel, Alchemy by Level Access , Amaze by Deque Systems. These solutions have never classed themselves at overlays. Including Tenon Sentinel that states “this is not an overlay”.

The advantages of these manual updated and testing solutions are promoted by Level, Deque, Tenon and UsableNet in different ways. Here are the links to the product pages that could be used to consolidate advantages and challenges they can address.

Amaze by Deque Systems

Sentinel by Tenon

[Alchemy by Level Access] https://www.oit.va.gov/Services/TRM/ToolPage.aspx?tid=13187

UsableNet Assistive by UsableNet

https://usablenet.com/technology/assistive-technology-services

taking Deque fact sheet here is their benefit list:

Deque has fixed over 1 million accessibility defects. That experience is in your hands when you get Amaze. Amaze works to ensure your web and mobile sites are accessible in the following ways • You have certainty that your site works cross-platform • You know that you can deliver responsive design • The tool that makes this happen for you is easy to use The complexity of accessibility requires the kind of expertise that Deque offers • You no longer need your internal developers to function as accessibility experts • You can be confident that accessibility fixes are applied properly to your legacy code • Third-party code is made accessible without requiring added internal investment

I hope this above helps establish the updates that could be considered and captures the new area of technolgy/approach that needs to be clarified .

Jason Taylor , UsableNet

[UsableNet-WCAG]

JS Overlay v jS plug-in

So getting technical and leveraging the W3c and US patent system for clear definitions of approaches that change a webpage. One could look at separating JS overlays from JS plug-ins.

web page overlays are commonly associated to windows, toolbars and widgets, something clearly visible. those are the bad accessibility tools that do not change page code (or limit the change) to improve accessibility, but add additional UI that pretends to substitute assistive technology or add complexity to the page.

Patent example:

https://patents.justia.com/patent/20060136822

Where JS Plug-in’s are a process where a JS file has been specifically written to change elements on a page, not adding an additional UI layer to deal with , but giving the browser of the user an updated code page.

Patent example:

https://patentimages.storage.googleapis.com/69/97/e8/c14dd43f2c6918/US7584435.pdf

- End

[karlgroves]

Apologies to participants in this thread. I haven't been getting notifications of responses. I'd like to create a PR for this in the next day or so and will post a comment here asking for review.

[karlgroves]

Please see commit: https://github.com/karlgroves/overlayfactsheet/commit/39943b343c14f6a560498edf92fb165c915da92a

Specifically places Amaze, Alchemy, and Sentinel in the list. Also adds Accessibility Adapter by ADA Site Compliance. Removes janky disclaimer previously applied to Amaze, Alchemy, and Sentinel. Provides a note that Alchemy and Sentinel are no longer developed or marketed.

Because Alchemy and Sentinel are no longer developed or marketed, it does beg the question about whether they should be listed at all, but I'd rather let the community comment on that.

[UsableNet-WCAG]

Hi Community,

These updates do not address the overall discussion in tickets #957 and #932. It was identified that this fact sheet is bunching many solutions under one definition and one list of weaknesses (there is only one strength). The list of what "can not be done" is not factually correct for all solutions listed . In #957 it was suggested that the fact sheet should separate out the three main groups of solutions. (1) Widgets that add only controls. (2) Solutions that rely on automated repair. (3) Manual approach that utilizes a JavaScript plug-in to update a page based on code written manually and checked manually. Each have their own advantages and challenges. They are all solutions that have a place in the market and this sheet should help companies of all sizes understand them based on balanced information.

This fact sheet is not educating the industry/market on how these three groups of solutions work and how each could have its own unique strengths and weaknesses.

I would also say these updates were made without community outreach, there is only really one or two people working on this list. The community of 600 that signed the original factsheet should be brought back into this discussion to help fully define the solutions, the differences, and the strengths and weaknesses of each.

In the previous tickets I have offered to help create content and that offer is still good.

[karlgroves]

@UsableNet-WCAG Feel free to create a PR that addresses the weaknesses you feel remain. For now, i feel that this does address #957 and will be closing this one, but a new issue & PR are welcome

[UsableNet-WCAG]

Hi all

I do not believe this addresses the lack of clarification on solutions that use JS plugin to update content based on manual only developed code. Which UsableNet Assistive falls into.

The original PR was challenged as UsableNet Assistive had been added to what is a list of automated overlays and widgets .

I have provided a number of references that help educate the difference. US patents etc.

Earlier in this Discussion is was identified to separate widgets only , automated solutions and manual solutions.

Considering the name of the page is fact sheet I would hope some facts can be considered.

I have added links to 3rd party article that outline some areas of strength. Currently the list of strength amd weaknesses is slanted to listing all the things automated solutions are not good at.

Manual JS Plugs solutions such as UsableNet assistive have some challenges but have benefits too. They can deliver what is needed, but they do take as much work as if original Dev do the work. But many companies can’t find Dev members right now. They do allow you to address short term, they do allow you to address 3rd party features. They do relay on outside service so to be sure that service is reliable and available.

I have offered to help with content to bring this fact sheet more online with the real differences and be more technically factual.

Today it is not credible to list just one strength and multiple weaknesses. It’s not credible to put all widgets, overlays and JS plugs-in , such as UsableNet Assistive all in one list under Overlays.

Ally overlays is a made up term. Not listed in W3C anywhere. 3wc however does cover UX overlays, in detail , but they would be more like widgets , adding something to the UX.

It seems non of these concerns have been. discussed or addressed with your changes.

Regards Jason Taylor

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 May 9, 2022, at 4:41 PM, Karl Groves @.***> wrote:



Please see commit: 39943b3https://github.com/karlgroves/overlayfactsheet/commit/39943b343c14f6a560498edf92fb165c915da92a

Specifically places Amaze, Alchemy, and Sentinel in the list. Also adds Accessibility Adapter by ADA Site Compliance. Removes janky disclaimer previously applied to Amaze, Alchemy, and Sentinel. Provides a note that Alchemy and Sentinel are no longer developed or marketed.

Because Alchemy and Sentinel are no longer developed or marketed, it does beg the question about whether they should be listed at all, but I'd rather let the community comment on that.

— Reply to this email directly, view it on GitHubhttps://github.com/karlgroves/overlayfactsheet/issues/957#issuecomment-1121561189, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATXNQE6TDCXOVWPA7RBHDOLVJFZ7JANCNFSM5T4OOZUQ. You are receiving this because you were mentioned.Message ID: @.***>