Based on ongoing discussions, this proposal suggests 8 new data-* attributes to be used for personalization needs. Not included in this initial set is an attribute proposal for content importance (a.k.a. simplification) or distraction

• data-literal
• data-numberfree
• data-easylang
• data-explain

The intention here is to provide, programmatically, alternative text values, not necessarily on images, but rather on any complex or confusing text values. In fact, the @alt attribute should NOT be invoked here (nor aria-label, aria-labeledby, or aria-describedby). A common component here is that the value of the new attributes will always take string text:

• <span data-numberfree="most">92%</span>
• <h1 data-easylang="form to ask for money if you have a disability or if you are ill">Disability claims under CD 356 / US </h1>
• It is <span data-literal="raining hard">raining cats and dogs</span>
• <button data-explain="press enter to send the email">Tell us today!</button>

Attribute values of data-feedback, data-moreinfo, and data-extrahelp would all take URLs (links to the explanation, feedback, more information or extra help), and are more appropriate in the following section (Purpose, Action or Destination.)

---

• data-purpose
• data-action
• data-destination

Data-inputs (fields) are already programmatically determined by using the <input> element, there is no need to redundantly add that information to the new attribute. The new attribute should mirror, as closely as possible (and I would argue exactly) the current WCAG 2.1 Success Criteria 1.3.5, up-to, and including the currently published token values, of which there are currently 53 values. Web authors will have a passing awareness of these already, as they are the tokens also used for @autocomplete, and the new proposed attribute for any form input (<input>) will mirror common and known authoring patterns today.

• <label for="foo">שם</label> <input type="text" id="foo" name="name" data-purpose="name">
• <label for="bar">Your Principle Residence</label> <input type="textarea" id="bar" name="address" data-purpose="street-address">

• To keep this page brief and readable, I will not list all of the proposed token values (53), however, they are (should be) the equivalent to what we have in WCAG 2.1 (SC 1.3.5)

(Note: the current collection of token values, when used with the @autocomplete attribute, are applicable only on the input type of text <input type="text"> (or, in the case of address, also on <textarea>. However, there currently are no @autocomplete values for input types of radio button, checkbox, or <select> - values which will need to be created/added to our specification.)

Putting aside the fact that many page authors are still unclear over choosing links versus buttons (links go to a new page or a section of the same page, buttons enact some kind of function or operation), for either the goal is to ensure that the user understands what will happen if or when they interact with that element. Generally, buttons will take an action value, whereas links will take a destination value. Some buttons (use-case: help modal) may take both values, if the action is to effectively render a new page somehow.

• <button data-action="undo">Revert</button>
• <a href="home.html" data-destination="home page">our main page</a>
• <button data-action="expand" data-destination="moreinfo">Learn More</button>

• sign in
• sign out
• sign up
• upload
• expand
• refresh
• print
• reset
• comment
• settings
• open
• close
• compose
• edit
• cut
• copy
• paste
• save
• delete
• undo
• cancel

• Read
• reply
• forwardto
• received
• send

• add (to cart)
• remove (from cart)
• buy (or) checkout

• home
• contact (us)
• about (us)
• ourPhone
• ourEmail
• sitemap
• help
• chat (help)
• services
• products
• terms
• explain
• feedback
• moreinfo
• extrahelp

---

• data-symbol

Symbols are a special type of simplification, where images take the place of text strings - for example a form label of "Address" could be rendered instead as a picture of a house (). Symbols alone however, while graphic elements, should not be called using the <img> element; rather one of two things should happen:

1. Individual symbol-sets should map their values to known token values, with the expectation that users who require symbols will already have a set of symbols installed on their computer (for use in both web pages, web applications and stand-alone computer programs). There are multiple symbol-sets and icon-sets available, and ideally the end-user will get the symbol they are accustomed to, rather than one dictated by the page author.
   For example, here are multiple instances of "home" (house): | | | | - it is not unreasonable to suggest that an end-user, anticipating this may not recognize that it is the equivalent to (or vice-versa).

2. However, expecting all users to have a specific symbol set installed may be overly optimistic, and so, as a fall-back authors could suggest a symbol taken from a common symbol set. If this were the case, user-agents that already have a symbol-set installed MUST ignore the author suggestion and render the appropriate pre-mapped symbol. Only when a pre-mapped symbol does not exist should the user-agent then apply the author suggested symbol on-demand:
   
   <label for="bar" data-symbol="URL for the symbol">Your Principle Residence</label> <input type="textarea" id="bar" name="address" data-purpose="street-address">
   
   Example: <label for="bar" data-symbol="http://blisssymbolics.org/refnumber/001">Your Principle Residence</label> <input type="textarea" id="bar" name="address" data-purpose="street-address">
   
   In this example, IF the data-purpose value has been mapped to a specific, installed symbol, THEN the user-agent will replace the <label>'s text value with the pre-mapped symbol. If however the user-agent has been flagged to always render symbols, but an existing symbol does not exist on the user's device, THEN the user-agent will source the referenced symbol provided by the author.
   
   @data-symbol MUST only take a URL reference to the actual symbol, and is used in conjunction with either purpose (form inputs), action (this button does what?), or destination (this link takes me where?)

• Ideally each of the token values used for data-purpose, data-action, and data-destination would also map to a unique symbol (at which point there would be no need to explicitly call for a symbol, as the user-agent would already have symbols related to all of those important functions, and would be configured to do the transformation on all content).
  (Question to be determined: should the specification explicitly re-state all of the token values used elsewhere here?)
• Page authors can none-the-less suggest a specific symbol with the understanding that it is only a hint, and that most users who require symbols for communication will already have one or more sets installed on their machine. In this case, the hint is furnished via a URL to the specific symbol being used