Re: [w3ctag/design-reviews] Personalization Semantics Explainer and  Module 1 (#476)

Thank you for the update.

At this point, we're not sure how much help we can be here. 

We're would like to reiterate that the work you have collectively done identifying the problems to solve is extremely good, and that the problems are real and should be solved.

However, we think we need to say more clearly that the shape of the solution as an ARIA-like vocabulary doesn't seem like a good fit.

ARIA had the characteristics that it was based on an existing vocabulary (MSAA), and was intended to be consumed by a single class of technologies (screen readers, later expanded to other types of assistive technologies.)

In contrast, this vocabulary seems like it would have a wide range of (programmatic) consumers, and it's not clear that those consumers have been brought in as stakeholders to this design process.

We would like to more strongly suggest that instead of trying to solve all of these problems with one solution, that you could take the excellent work already done identifying problems, and look at solving them individually, working with the relevant stakeholders. The relevant stakeholders may include users, authors, publishers, assistive technology creators, and potentially others as well. 

This aligns with our general design principles: we advise _all_ API authors to [prefer simple solutions](https://w3ctag.github.io/design-principles/#simplicity).

Some of these problems may be "stickier" than others; for example, trying to come up with a system to allow users to avoid unwelcome distraction from revenue-generating ads is going to involve buy-in from the publishers who need that revenue in order to keep operating as a business.

However, other problems, like annotating words with the relevant Bliss or other symbol, seem very well scoped in terms of user need, authoring responsibility, and assistive technology implementation requirements.

Not all of these solutions may even need to go through a standardisation process immediately, but may be better suited to [incubation](https://wicg.io/) to allow prototyping and rapid iteration as a collaborative process with the various stakeholders, before settling on a standard.

We know this is not the feedback you were likely hoping for, but we would like to emphasise how rare it is that we get a proposal with the level of work put in to user needs as we have seen here, and that this is one of the most critical parts of the design process.

We would welcome the opportunity to continue working with you on better scoped proposals to address subsets of the user needs you have identified, including very early stage ideas in incubation.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/476#issuecomment-767947210