@markuplint/html-spec 4.0.0-alpha.5 → 4.0.0-dev.0

package/index.json

@@ -2893,7 +2893,7 @@
 					},
 					{
 						"name": "cell",
-						"description": "A cell in a tabular container. See related gridcell.\n\nAuthors MUST ensure elements with role cell are contained in, or owned by, an element with the role row.",
+						"description": "A cell in a tabular container. See related gridcell.\n\nAuthors MUST ensure elements with role cell are the accessibility children of an element with the role row.",
 						"generalization": ["section"],
 						"requiredContextRole": ["row"],
 						"requiredOwnedElements": [],
@@ -3250,7 +3250,7 @@
 					},
 					{
 						"name": "columnheader",
-						"description": "A cell containing header information for a column.\n\ncolumnheader can be used as a column header in a table or grid. It could also be used in a pie chart to show a similar relationship in the data.\n\nThe columnheader establishes a relationship between it and all cells in the corresponding column. It is the structural equivalent to an HTML th element with a column scope.\n\nAuthors MUST ensure elements with role columnheader are contained in, or owned by, an element with the role row.\n\nApplying the aria-selected state on a columnheader MUST not cause the user agent to automatically propagate the aria-selected state to all the cells in the corresponding column. An author MAY choose to propagate selection in this manner depending on the specific application.\n\nWhile the columnheader role can be used in both interactive grids and non-interactive tables, the use of aria-readonly and aria-required is only applicable to interactive elements. Therefore, authors SHOULD NOT use aria-required or aria-readonly in a columnheader that descends from a table, and user agents SHOULD NOT expose either property to assistive technologies unless the columnheader descends from a grid.\n\nBecause cells are organized into rows, there is not a single container element for the column. The column is the set of gridcell elements in a particular position within their respective row containers.\n\nWhile aria-disabled is currently supported on columnheader, in a future version the working group plans to prohibit its use on elements with role columnheader except when the element is in the context of a grid or treegrid.",
+						"description": "A cell containing header information for a column.\n\ncolumnheader can be used as a column header in a table or grid. It could also be used in a pie chart to show a similar relationship in the data.\n\nThe columnheader establishes a relationship between it and all cells in the corresponding column. It is the structural equivalent to an HTML th element with a column scope.\n\nAuthors MUST ensure elements with role columnheader are the accessibility children of an element with the role row.\n\nApplying the aria-selected state on a columnheader MUST not cause the user agent to automatically propagate the aria-selected state to all the cells in the corresponding column. An author MAY choose to propagate selection in this manner depending on the specific application.\n\nWhile the columnheader role can be used in both interactive grids and non-interactive tables, the use of aria-readonly and aria-required is only applicable to interactive elements. Therefore, authors SHOULD NOT use aria-required or aria-readonly in a columnheader that descends from a table, and user agents SHOULD NOT expose either property to assistive technologies unless the columnheader descends from a grid.\n\nBecause cells are organized into rows, there is not a single container element for the column. The column is the set of gridcell elements in a particular position within their respective row containers.\n\nWhile aria-disabled is currently supported on columnheader, in a future version the working group plans to prohibit its use on elements with role columnheader except when the element is in the context of a grid or treegrid.",
 						"generalization": ["cell", "gridcell", "sectionhead"],
 						"requiredContextRole": ["row"],
 						"requiredOwnedElements": [],
@@ -3877,7 +3877,7 @@
 					},
 					{
 						"name": "composite",
-						"description": "A widget that can contain navigable descendants or owned children.\n\nAuthors SHOULD ensure that a composite widget exists as a single navigation stop within the larger navigation system of the web page. Once the composite widget has focus, authors SHOULD provide a separate navigation mechanism for users to navigate to elements that are descendants or owned children of the composite element.\n\ncomposite is an abstract role used for the ontology. Authors MUST NOT use composite role in content.",
+						"description": "A widget that can contain navigable accessibility descendants.\n\nAuthors SHOULD ensure that a composite widget exists as a single navigation stop within the larger navigation system of the web page. Once the composite widget has focus, authors SHOULD provide a separate navigation mechanism for users to navigate to elements that are accessibility descendants of the composite element.\n\ncomposite is an abstract role used for the ontology. Authors MUST NOT use composite role in content.",
 						"isAbstract": true,
 						"generalization": ["widget"],
 						"requiredContextRole": [],
@@ -5201,7 +5201,7 @@
 					},
 					{
 						"name": "grid",
-						"description": "A composite widget containing a collection of one or more rows with one or more cells where some or all cells in the grid are focusable by using methods of two-dimensional navigation, such as directional arrow keys.\n\nThe grid role does not imply a specific visual, e.g., tabular, presentation. It describes relationships among elements. It can be used for purposes as simple as grouping a collection of checkboxes or navigation links or as complex as creating a full-featured spreadsheet application.\n\nThe cell elements of a grid have role gridcell. Authors MAY designate a cell as a row or column header by using either the rowheader or columnheader role in lieu of the gridcell role. Authors MUST ensure elements with role gridcell, columnheader, or rowheader are owned by elements with role row, which are in turn owned by an element with role rowgroup, or grid.\n\nTo be keyboard accessible, authors SHOULD manage focus of descendants of a grid as described in Managing Focus. When a user is navigating the grid content with a keyboard, authors SHOULD set focus as follows:\n\nAuthors SHOULD provide a mechanism for changing to an interaction or edit mode that allows users to navigate and interact with content contained inside a focusable cell if that focusable cell contains any of the following:\n\nFor example, if a cell in a spreadsheet contains a combobox or editable text, the Enter key might be used to activate a cell interaction or editing mode when that cell has focus so the directional arrow keys can be used to operate the contained combobox or textbox. Depending on the implementation, pressing Enter again, Tab, Escape, or another key might switch the application back to the grid navigation mode.\n\nAuthors MAY use a gridcell to display the result of a formula, which could be editable by the user. In a spreadsheet application, for example, a gridcell might show a value calculated from a formula until the user activates the gridcell for editing when a textbox appears in the gridcell containing the formula in an editable state.\n\nIf aria-readonly is set on an element with role grid, user agents MUST propagate the value to all gridcell elements owned by the grid and expose the value in the accessibility API. An author MAY override the propagated value of aria-readonly for an individual gridcell element.\n\nIn a grid that provides cell content editing functions, if the content of a focusable gridcell element is not editable, authors MAY set aria-readonly to true on the gridcell element. However, the value of aria-readonly, whether specified for a grid or individual cells, only indicates whether the content contained in cells is editable. It does not represent availability of functions for navigating or manipulating the grid itself.\n\nAn unspecified value for aria-readonly does not imply that a grid or a gridcell contains editable content. For example, if a grid presents a collection of elements that are not editable, such as a collection of link elements representing dates in a datepicker, it is not necessary for the author to specify a value for aria-readonly.\n\nAuthors MAY indicate that a focusable gridcell is selectable as the object of an action with the aria-selected attribute. If the grid allows multiple gridcells to be selected, the author SHOULD set aria-multiselectable to true on the element with role grid.\n\nSince WAI-ARIA can augment an element of the host language, a grid can reuse the elements and attributes of a native table, such as an HTML table element. For example, if an author applies the grid role to an HTML table element, the author does not need to apply the row and gridcell roles to the descendant HTML tr and td elements because the user agent will automatically make the appropriate translations. When the author is reusing a native host language table element and needs a gridcell element to span multiple rows or columns, the author SHOULD apply the appropriate host language attributes instead of WAI-ARIA aria-rowspan or aria-colspan properties.\n\nSee the WAI-ARIA Authoring Practices for additional details on implementing grid design patterns.",
+						"description": "A composite widget containing a collection of one or more rows with one or more cells where some or all cells in the grid are focusable by using methods of two-dimensional navigation, such as directional arrow keys.\n\nThe grid role does not imply a specific visual, e.g., tabular, presentation. It describes relationships among elements. It can be used for purposes as simple as grouping a collection of checkboxes or navigation links or as complex as creating a full-featured spreadsheet application.\n\nThe cell elements of a grid have role gridcell. Authors MAY designate a cell as a row or column header by using either the rowheader or columnheader role in lieu of the gridcell role. Authors MUST ensure elements with role gridcell, columnheader, or rowheader are accessibility children of elements with role row, which are in turn are accessibility children of an element with role rowgroup, or grid.\n\nTo be keyboard accessible, authors SHOULD manage focus of descendants of a grid as described in Managing Focus. When a user is navigating the grid content with a keyboard, authors SHOULD set focus as follows:\n\nAuthors SHOULD provide a mechanism for changing to an interaction or edit mode that allows users to navigate and interact with content contained inside a focusable cell if that focusable cell contains any of the following:\n\nFor example, if a cell in a spreadsheet contains a combobox or editable text, the Enter key might be used to activate a cell interaction or editing mode when that cell has focus so the directional arrow keys can be used to operate the contained combobox or textbox. Depending on the implementation, pressing Enter again, Tab, Escape, or another key might switch the application back to the grid navigation mode.\n\nAuthors MAY use a gridcell to display the result of a formula, which could be editable by the user. In a spreadsheet application, for example, a gridcell might show a value calculated from a formula until the user activates the gridcell for editing when a textbox appears in the gridcell containing the formula in an editable state.\n\nIf aria-readonly is set on an element with role grid, user agents MUST propagate the value to all gridcell elements that are accessibility descendants of that grid and expose the value in the accessibility API. An author MAY override the propagated value of aria-readonly for an individual gridcell element.\n\nIn a grid that provides cell content editing functions, if the content of a focusable gridcell element is not editable, authors MAY set aria-readonly to true on the gridcell element. However, the value of aria-readonly, whether specified for a grid or individual cells, only indicates whether the content contained in cells is editable. It does not represent availability of functions for navigating or manipulating the grid itself.\n\nAn unspecified value for aria-readonly does not imply that a grid or a gridcell contains editable content. For example, if a grid presents a collection of elements that are not editable, such as a collection of link elements representing dates in a datepicker, it is not necessary for the author to specify a value for aria-readonly.\n\nAuthors MAY indicate that a focusable gridcell is selectable as the object of an action with the aria-selected attribute. If the grid allows multiple gridcells to be selected, the author SHOULD set aria-multiselectable to true on the element with role grid.\n\nSince WAI-ARIA can augment an element of the host language, a grid can reuse the elements and attributes of a native table, such as an HTML table element. For example, if an author applies the grid role to an HTML table element, the author does not need to apply the row and gridcell roles to the descendant HTML tr and td elements because the user agent will automatically make the appropriate translations. When the author is reusing a native host language table element and needs a gridcell element to span multiple rows or columns, the author SHOULD apply the appropriate host language attributes instead of WAI-ARIA aria-rowspan or aria-colspan properties.\n\nSee the WAI-ARIA Authoring Practices for additional details on implementing grid design patterns.",
 						"generalization": ["composite", "table"],
 						"requiredContextRole": [],
 						"requiredOwnedElements": ["caption", "row", "rowgroup > row"],
@@ -5332,7 +5332,7 @@
 					},
 					{
 						"name": "gridcell",
-						"description": "A cell in a grid or treegrid.\n\nA gridcell can be focusable, editable, and selectable. A gridcell can have relationships such as aria-controls to address the application of functional relationships.\n\nIf an author intends a gridcell to have a row header, column header, or both, and if the relevant headers cannot be determined from the DOM structure, authors SHOULD explicitly indicate which header cells are relevant to the gridcell by applying aria-describedby on the gridcell and referencing elements with role rowheader or columnheader.\n\nIn a treegrid, authors MAY define a gridcell as expandable by using the aria-expanded attribute. If the aria-expanded attribute is provided, it applies only to the individual cell. It is not a proxy for the container row, which also can be expanded. The main use case for providing this attribute on a gridcell is pivot table behavior.\n\nAuthors MUST ensure elements with role gridcell are contained in, or owned by, an element with the role row.",
+						"description": "A cell in a grid or treegrid.\n\nA gridcell can be focusable, editable, and selectable. A gridcell can have relationships such as aria-controls to address the application of functional relationships.\n\nIf an author intends a gridcell to have a row header, column header, or both, and if the relevant headers cannot be determined from the DOM structure, authors SHOULD explicitly indicate which header cells are relevant to the gridcell by applying aria-describedby on the gridcell and referencing elements with role rowheader or columnheader.\n\nIn a treegrid, authors MAY define a gridcell as expandable by using the aria-expanded attribute. If the aria-expanded attribute is provided, it applies only to the individual cell. It is not a proxy for the container row, which also can be expanded. The main use case for providing this attribute on a gridcell is pivot table behavior.\n\nAuthors MUST ensure elements with role gridcell are accessibility children of an element with the role row.",
 						"generalization": ["cell", "widget"],
 						"requiredContextRole": ["row"],
 						"requiredOwnedElements": [],
@@ -6521,7 +6521,7 @@
 					},
 					{
 						"name": "listitem",
-						"description": "A single item in a list or directory.\n\nAuthors MUST ensure elements whose role is listitem are contained in, or owned by, an element whose role is list.",
+						"description": "A single item in a list or directory.\n\nAuthors MUST ensure elements whose role is listitem are accessibility children of an element whose role is list.",
 						"generalization": ["section"],
 						"requiredContextRole": ["directory", "list"],
 						"requiredOwnedElements": [],
@@ -7457,7 +7457,7 @@
 					},
 					{
 						"name": "menuitem",
-						"description": "An option in a set of choices contained by a menu or menubar.\n\nAuthors MUST ensure elements with role menuitem are contained in, or owned by, an element with role menu or an element with role group that is contained in, or owned by, an element with role menu.\n\nAuthors MAY disable a menu item with the aria-disabled attribute. If the menu item has its aria-haspopup attribute set to true, it indicates that the menu item can be used to launch a sub-level menu, and authors SHOULD display a new sub-level menu when the menu item is activated.\n\nIn order to identify that they are related widgets, authors MUST ensure that menu items are owned by an element with role menu or menubar. Authors MAY separate menu items into sets by use of a separator or an element with an equivalent role from the native markup language.",
+						"description": "An option in a set of choices contained by a menu or menubar.\n\nAuthors MUST ensure elements with role menuitem are accessibility children of an element with role menu or an element with role group that is an accessibility child of an element with role menu.\n\nAuthors MAY disable a menu item with the aria-disabled attribute. If the menu item has its aria-haspopup attribute set to true, it indicates that the menu item can be used to launch a sub-level menu, and authors SHOULD display a new sub-level menu when the menu item is activated.\n\nIn order to identify that they are related widgets, authors MUST ensure that menu items are accessibility descendants of an element with role menu or menubar. Authors MAY separate menu items into sets by use of a separator or an element with an equivalent role from the native markup language.",
 						"generalization": ["command"],
 						"requiredContextRole": ["menu", "menubar", "menu > group", "menubar > group"],
 						"requiredOwnedElements": [],
@@ -7576,7 +7576,7 @@
 					},
 					{
 						"name": "menuitemcheckbox",
-						"description": "A menuitem with a checkable state whose possible values are true, false, or mixed.\n\nAuthors MUST ensure elements with role menuitemcheckbox are contained in, or owned by, an element with role menu or an element with role group that is contained in, or owned by, an element with role menu.\n\nThe aria-checked attribute of a menuitemcheckbox indicates whether the menu item is checked (true), unchecked (false), or represents a sub-level menu of other menu items that have a mixture of checked and unchecked values (mixed).\n\nIn order to identify that they are related widgets, authors MUST ensure that menu item checkboxes are owned by an element with role menu or menubar. Authors MAY separate menu items into sets by use of a separator or an element with an equivalent role from the native markup language.",
+						"description": "A menuitem with a checkable state whose possible values are true, false, or mixed.\n\nAuthors MUST ensure elements with role menuitemcheckbox are accessibility children of an element with role menu or an element with role group that is the accessibility child of an element with role menu.\n\nThe aria-checked attribute of a menuitemcheckbox indicates whether the menu item is checked (true), unchecked (false), or represents a sub-level menu of other menu items that have a mixture of checked and unchecked values (mixed).\n\nIn order to identify that they are related widgets, authors MUST ensure that menu item checkboxes are the accessibility descendants of an element with role menu or menubar. Authors MAY separate menu items into sets by use of a separator or an element with an equivalent role from the native markup language.",
 						"generalization": ["menuitem"],
 						"requiredContextRole": ["menu", "menubar", "menu > group", "menubar > group"],
 						"requiredOwnedElements": [],
@@ -7705,7 +7705,7 @@
 					},
 					{
 						"name": "menuitemradio",
-						"description": "A checkable menuitem in a set of elements with the same role, only one of which can be checked at a time.\n\nAuthors MUST ensure elements with role menuitemradio are contained in, or owned by, an element with role menu or an element with role group that is contained in, or owned by, an element with role menu.\n\nAuthors SHOULD enforce that only one menuitemradio in a group can be checked at the same time. When one item in the group is checked, the previously checked item becomes unchecked (its aria-checked attribute becomes false).\n\nIn order to identify that they are related widgets, authors MUST ensure that menu item radios are owned by an element with role menu or menubar, or by a role group which itself is owned by an element with role menu or menubar.\n\nIf a menu or menubar contains more than one group of menuitemradio elements, or if the menu contains one group and other, unrelated menu items, authors SHOULD contain each set of related menuitemradio elements in an element using the group role. Authors MAY also delimit the group from other menu items with an element using the separator role, or an element with an equivalent role from the native markup language.",
+						"description": "A checkable menuitem in a set of elements with the same role, only one of which can be checked at a time.\n\nAuthors MUST ensure elements with role menuitemradio are accessibility children of an element with role menu or of an element with role group that is the accessibility child of an element with role menu.\n\nAuthors SHOULD enforce that only one menuitemradio in a group can be checked at the same time. When one item in the group is checked, the previously checked item becomes unchecked (its aria-checked attribute becomes false).\n\nIn order to identify that they are related widgets, authors MUST ensure that menu item radios are accessibility descendants of an element with role menu or menubar.\n\nIf a menu or menubar contains more than one group of menuitemradio elements, or if the menu contains one group and other, unrelated menu items, authors SHOULD contain each set of related menuitemradio elements in an element using the group role. Authors MAY also delimit the group from other menu items with an element using the separator role, or an element with an equivalent role from the native markup language.",
 						"generalization": ["menuitem"],
 						"requiredContextRole": ["menu", "menubar", "menu > group", "menubar > group"],
 						"requiredOwnedElements": [],
@@ -8079,7 +8079,7 @@
 					},
 					{
 						"name": "none",
-						"description": "An element whose implicit native role semantics will not be mapped to the accessibility API. See synonym presentation.\n\nIn ARIA 1.1, the working group introduced none as a synonym to the presentation role, due to author confusion surrounding the intended meaning of the word \"presentation\" or \"presentational.\" Many individuals erroneously consider role=\"presentation\" to be synonymous with aria-hidden=\"true\", and we believe role=\"none\" conveys the actual meaning more unambiguously.\n\nThe intended use is when an element is used to change the look of the page but does not have all the functional, interactive, or structural relevance implied by the element type, or can be used to provide for an accessible fallback in older browsers that do not support WAI-ARIA.\n\nExample use cases:\n\nFor any element with a role of none/presentation and which is not focusable, the user agent MUST NOT expose the implicit native semantics of the element (the role and its states and properties) to accessibility APIs. However, the user agent MUST expose content and descendant elements that do not have an explicit or inherited role of none/presentation. Thus, the none/presentation role causes a given element to be treated as having no role or to be removed from the accessibility tree, but does not cause the content contained within the element to be removed from the accessibility tree.\n\nFor example, the following two markup snippets will be exposed similarly to an accessibility API.\n\nIn HTML, the <img> element is treated as a single entity regardless of the type of image file. Consequently, using role=\"none\" or role=\"presentation\" on an HTML img is equivalent to using aria-hidden=\"true\". In order to make the image contents accessible, authors can embed the object using an <object> or <iframe> element, or use inline SVG code, and follow the accessibility guidelines for the image content.\n\nAuthors SHOULD NOT provide meaningful alternative text (for example, use alt=\"\" in HTML) when the none/presentation role is applied to an image.\n\nIn the following code sample, the containing img and is appropriately labeled by the caption paragraph. In this example the img element can be marked as none/presentation because the role and the text alternatives are provided by the containing element.\n\nIn the following code sample, because the anchor (HTML a element) is acting as the treeitem, the list item (HTML li element) is assigned an explicit WAI-ARIA role of none/presentation to override the user agent's implicit native semantics for list items.\n\nThe none/presentation role is used on an element that has implicit native semantics, meaning that there is a default accessibility API role for the element. Some elements are only complete when additional descendant elements are provided. For example, in HTML, table elements (matching the table role) require tr descendants (which have an implicit row role), which in turn require th or td children (the columnheader or rowheader and cell roles, respectively). Similarly, lists require list item children. The descendant elements that complete the semantics of an element are described in WAI-ARIA as Allowed Accessibility Child Roles.\n\nWhen an explicit or inherited role of none/presentation is applied to an element with the implicit semantic of a WAI-ARIA role that has Allowed Accessibility Child Roles, in addition to the element with the explicit role of none/presentation, the user agent MUST apply an inherited role of none to any owned elements that do not have an explicit role defined. Also, when an explicit or inherited role of none/presentation is applied to a host language element which has specifically allowed children as defined by the host language specification, in addition to the element with the explicit role of none/presentation, the user agent MUST apply an inherited role of none to any specifically allowed children that do not have an explicit role defined.\n\nFor any element with an explicit or inherited role of none/presentation and which is not focusable, user agents MUST ignore role-specific WAI-ARIA states and properties for that element. For example, in HTML, a ul or ol element with a role of none/presentation will have the implicit native semantics of its li elements removed because the list role to which the ul or ol corresponds has an Allowed Accessibility Child Role of listitem. Likewise, the implicit native semantics of an HTML table element's thead/tbody/tfoot/tr/th/td descendants will also be removed, because the HTML specification indicates that these are required structural descendants of the table element.\n\nOnly the implicit native semantics of elements that correspond to WAI-ARIA Allowed Accessibility Child Roles are removed. All other content remains intact, including nested tables or lists, unless those elements also have an explicit role of none/presentation specified.\n\nFor example, according to an accessibility API, the following markup elements might have identical or very similar role semantics (generic or none role) and identical content.\n\nThere are other WAI-ARIA roles with specific allowed children for which this situation is applicable (e.g., feeds and listboxes), but tables and lists are the most common real-world cases in which the none/presentation inheritance is likely to apply.\n\nFor any element with an explicit or inherited role of none/presentation, user agents MUST apply an inherited role of none to all host-language-specific labeling elements for the presentational element. For example, a table element with a role of none/presentation will have the implicit native semantics of its caption element removed, because the caption is merely a label for the presentational table.\n\nInformation about resolving conflicts in the none/presentation role has been moved to Handling Author Errors",
+						"description": "An element whose implicit native role semantics will not be mapped to the accessibility API. See synonym presentation.\n\nIn ARIA 1.1, the working group introduced none as a synonym to the presentation role, due to author confusion surrounding the intended meaning of the word \"presentation\" or \"presentational.\" Many individuals erroneously consider role=\"presentation\" to be synonymous with aria-hidden=\"true\", and we believe role=\"none\" conveys the actual meaning more unambiguously.\n\nThe intended use is when an element is used to change the look of the page but does not have all the functional, interactive, or structural relevance implied by the element type, or can be used to provide for an accessible fallback in older browsers that do not support WAI-ARIA.\n\nExample use cases:\n\nFor any element with a role of none/presentation and which is not focusable, the user agent MUST NOT expose the implicit native semantics of the element (the role and its states and properties) to accessibility APIs. However, the user agent MUST expose content and descendant elements that do not have an explicit or inherited role of none/presentation. Thus, the none/presentation role causes a given element to be treated as having no role or to be removed from the accessibility tree, but does not cause the content contained within the element to be removed from the accessibility tree.\n\nFor example, the following two markup snippets will be exposed similarly to an accessibility API.\n\nIn HTML, the <img> element is treated as a single entity regardless of the type of image file. Consequently, using role=\"none\" or role=\"presentation\" on an HTML img is equivalent to using aria-hidden=\"true\". In order to make the image contents accessible, authors can embed the object using an <object> or <iframe> element, or use inline SVG code, and follow the accessibility guidelines for the image content.\n\nAuthors SHOULD NOT provide a meaningful text alternative (for example, use alt=\"\" in HTML) when the none/presentation role is applied to an image.\n\nIn the following code sample, the containing img and is appropriately labeled by the caption paragraph. In this example the img element can be marked as none/presentation because the role and the text alternatives are provided by the containing element.\n\nIn the following code sample, because the anchor (HTML a element) is acting as the treeitem, the list item (HTML li element) is assigned an explicit WAI-ARIA role of none/presentation to override the user agent's implicit native semantics for list items.\n\nThe none/presentation role is used on an element that has implicit native semantics, meaning that there is a default accessibility API role for the element. Some elements are only complete when additional descendant elements are provided. For example, in HTML, table elements (matching the table role) require tr descendants (which have an implicit row role), which in turn require th or td children (the columnheader or rowheader and cell roles, respectively). Similarly, lists require list item children. The descendant elements that complete the semantics of an element are described in WAI-ARIA as Allowed Accessibility Child Roles.\n\nWhen an explicit or inherited role of none/presentation is applied to an element with the implicit semantic of a WAI-ARIA role that has Allowed Accessibility Child Roles, in addition to the element with the explicit role of none/presentation, the user agent MUST apply an inherited role of none to any accessibility descendants that do not have an explicit role defined. Also, when an explicit or inherited role of none/presentation is applied to a host language element which has specifically allowed children as defined by the host language specification, in addition to the element with the explicit role of none/presentation, the user agent MUST apply an inherited role of none to any specifically allowed children that do not have an explicit role defined.\n\nFor any element with an explicit or inherited role of none/presentation and which is not focusable, user agents MUST ignore role-specific WAI-ARIA states and properties for that element. For example, in HTML, a ul or ol element with a role of none/presentation will have the implicit native semantics of its li elements removed because the list role to which the ul or ol corresponds has an Allowed Accessibility Child Role of listitem. Likewise, the implicit native semantics of an HTML table element's thead/tbody/tfoot/tr/th/td descendants will also be removed, because the HTML specification indicates that these are required structural descendants of the table element.\n\nOnly the implicit native semantics of elements that correspond to WAI-ARIA Allowed Accessibility Child Roles are removed. All other content remains intact, including nested tables or lists, unless those elements also have an explicit role of none/presentation specified.\n\nFor example, according to an accessibility API, the following markup elements might have identical or very similar role semantics (generic or none role) and identical content.\n\nThere are other WAI-ARIA roles with specific allowed children for which this situation is applicable (e.g., feeds and listboxes), but tables and lists are the most common real-world cases in which the none/presentation inheritance is likely to apply.\n\nFor any element with an explicit or inherited role of none/presentation, user agents MUST apply an inherited role of none to all host-language-specific labeling elements for the presentational element. For example, a table element with a role of none/presentation will have the implicit native semantics of its caption element removed, because the caption is merely a label for the presentational table.\n\nInformation about resolving conflicts in the none/presentation role has been moved to Handling Author Errors",
 						"generalization": ["structure"],
 						"requiredContextRole": [],
 						"requiredOwnedElements": [],
@@ -8295,7 +8295,7 @@
 					},
 					{
 						"name": "option",
-						"description": "An item in a listbox.\n\nAuthors MUST ensure elements with role option are contained in, or owned by, an element with role listbox or an element with role group that is contained in, or owned by, an element with role listbox. Options not associated with a listbox might not be correctly mapped to an accessibility API.\n\nIn certain conditions, a user agent MAY provide an implicit value for aria-selected for each option in a listbox, and if it does, the user agent MUST ensure the following conditions are met before providing an implicit value:\n\nIf a user agent provides an implicit aria-selected value for an option, the value SHOULD be true if the option has DOM focus or the listbox has DOM focus and the option is referenced by aria-activedescendant. Otherwise, if a user agent provides an implicit aria-selected value for an option, the value SHOULD be false.\n\nAuthors SHOULD indicate selection for option elements using one of the following:\n\nAuthors SHOULD NOT specify both aria-selected and aria-checked on option elements contained by the same listbox except in the extremely rare circumstances where all the following conditions are met:",
+						"description": "An item in a listbox.\n\nAuthors MUST ensure elements with role option are accessibility children of an element with role listbox or of an element with role group that is the accessibility child of an element with role listbox. Options not associated with a listbox might not be correctly mapped to an accessibility API.\n\nIn certain conditions, a user agent MAY provide an implicit value for aria-selected for each option in a listbox, and if it does, the user agent MUST ensure the following conditions are met before providing an implicit value:\n\nIf a user agent provides an implicit aria-selected value for an option, the value SHOULD be true if the option has DOM focus or the listbox has DOM focus and the option is referenced by aria-activedescendant. Otherwise, if a user agent provides an implicit aria-selected value for an option, the value SHOULD be false.\n\nAuthors SHOULD indicate selection for option elements using one of the following:\n\nAuthors SHOULD NOT specify both aria-selected and aria-checked on option elements contained by the same listbox except in the extremely rare circumstances where all the following conditions are met:",
 						"generalization": ["input"],
 						"requiredContextRole": ["listbox", "listbox > group"],
 						"requiredOwnedElements": [],
@@ -9335,16 +9335,9 @@
 					},
 					{
 						"name": "row",
-						"description": "A row of cells in a tabular container.\n\nRows contain cell or gridcell elements, and thus serve to organize a table, grid, or treegrid.\n\nWhile the row role can be used in a table, grid, or treegrid, the semantics of aria-expanded, aria-posinset, aria-setsize, and aria-level are only applicable to the hierarchical structure of an interactive tree grid. Therefore, authors MUST NOT apply aria-expanded, aria-posinset, aria-setsize, and aria-level to a row that descends from a table or grid, and user agents SHOULD NOT expose any of these four properties to assistive technologies unless the row descends from a treegrid.\n\nAuthors MUST ensure elements with role row are contained in, or owned by, an element with the role table, grid, rowgroup, or treegrid.\n\nWhile aria-disabled is currently supported on row, in a future version the working group plans to prohibit its on elements with role row except when the element is in the context of a grid or treegrid.",
+						"description": "A row of cells in a tabular container.\n\nRows contain cell or gridcell elements, and thus serve to organize a table, grid, or treegrid.\n\nWhile the row role can be used in a table, grid, or treegrid, the semantics of aria-expanded, aria-posinset, aria-setsize, and aria-level are only applicable to the hierarchical structure of an interactive tree grid. Therefore, authors MUST NOT apply aria-expanded, aria-posinset, aria-setsize, and aria-level to a row that descends from a table or grid, and user agents SHOULD NOT expose any of these four properties to assistive technologies unless the row descends from a treegrid.\n\nAuthors MUST ensure elements with role row are accessibility children of an element with the role table, grid, rowgroup, or treegrid.\n\nWhile aria-disabled is currently supported on row, in a future version the working group plans to prohibit its on elements with role row except when the element is in the context of a grid or treegrid.",
 						"generalization": ["group", "widget"],
-						"requiredContextRole": [
-							"grid",
-							"table",
-							"treegrid",
-							"grid > rowgroup",
-							"table > rowgroup",
-							"treegrid > rowgroup"
-						],
+						"requiredContextRole": ["grid", "table", "treegrid", "rowgroup"],
 						"requiredOwnedElements": ["cell", "columnheader", "gridcell", "rowheader"],
 						"accessibleNameRequired": false,
 						"accessibleNameFromAuthor": true,
@@ -9483,7 +9476,7 @@
 					},
 					{
 						"name": "rowgroup",
-						"description": "A structure containing one or more row elements in a tabular container.\n\nThe rowgroup role establishes a relationship between owned row elements. It is a structural equivalent to the thead, tfoot, and tbody elements in an HTML table element.\n\nAuthors MUST ensure elements with role rowgroup are contained in, or owned by, an element with the role grid, table, or treegrid.\n\nThe rowgroup role exists, in part, to support role symmetry in HTML, and allows for the propagation of presentation inheritance on HTML table elements with an explicit presentation role applied.\n\nThis role does not differentiate between types of row groups (e.g., thead vs. tbody), but an issue has been raised for WAI-ARIA 2.0.",
+						"description": "A structure containing one or more row elements in a tabular container.\n\nThe rowgroup role establishes a relationship with its accessibility children of role row. It is a structural equivalent to the thead, tfoot, and tbody elements in an HTML table element.\n\nAuthors MUST ensure elements with role rowgroup are accessibility children of an element with the role grid, table, or treegrid.\n\nThe rowgroup role exists, in part, to support role symmetry in HTML, and allows for the propagation of presentation inheritance on HTML table elements with an explicit presentation role applied.\n\nThis role does not differentiate between types of row groups (e.g., thead vs. tbody), but an issue has been raised for WAI-ARIA 2.0.",
 						"generalization": ["structure"],
 						"requiredContextRole": ["grid", "table", "treegrid"],
 						"requiredOwnedElements": ["row"],
@@ -9597,7 +9590,7 @@
 					},
 					{
 						"name": "rowheader",
-						"description": "A cell containing header information for a row.\n\nThe rowheader role can be used to identify a cell as a header for a row in a table, grid, or treegrid. The rowheader establishes a relationship between it and all cells in the corresponding row. It is a structural equivalent to setting scope=\"row\" on an HTML th element.\n\nAuthors MUST ensure elements with role rowheader are contained in, or owned by, an element with the role row.\n\nApplying the aria-selected state on a rowheader MUST NOT cause the user agent to automatically propagate the aria-selected state to all the cells in the corresponding row. An author MAY choose to propagate selection in this manner depending on the specific application.\n\nWhile the rowheader role can be used in both interactive grids and non-interactive tables, the use of aria-expanded, aria-readonly, and aria-required is only applicable to interactive elements. Therefore, authors SHOULD NOT use aria-expanded, aria-readonly, or aria-required in a rowheader that descends from a table, and user agents SHOULD NOT expose these properties to assistive technologies unless the rowheader descends from a grid or treegrid.\n\nWhile aria-disabled is currently supported on rowheader, in a future version the working group plans to prohibit its use on elements with role rowheader except when the element is in the context of a grid or treegrid.",
+						"description": "A cell containing header information for a row.\n\nThe rowheader role can be used to identify a cell as a header for a row in a table, grid, or treegrid. The rowheader establishes a relationship between it and all cells in the corresponding row. It is a structural equivalent to setting scope=\"row\" on an HTML th element.\n\nAuthors MUST ensure elements with role rowheader are accessibility children of an element with the role row.\n\nApplying the aria-selected state on a rowheader MUST NOT cause the user agent to automatically propagate the aria-selected state to all the cells in the corresponding row. An author MAY choose to propagate selection in this manner depending on the specific application.\n\nWhile the rowheader role can be used in both interactive grids and non-interactive tables, the use of aria-expanded, aria-readonly, and aria-required is only applicable to interactive elements. Therefore, authors SHOULD NOT use aria-expanded, aria-readonly, or aria-required in a rowheader that descends from a table, and user agents SHOULD NOT expose these properties to assistive technologies unless the rowheader descends from a grid or treegrid.\n\nWhile aria-disabled is currently supported on rowheader, in a future version the working group plans to prohibit its use on elements with role rowheader except when the element is in the context of a grid or treegrid.",
 						"generalization": ["cell", "gridcell", "sectionhead"],
 						"requiredContextRole": ["row"],
 						"requiredOwnedElements": [],
@@ -10735,7 +10728,7 @@
 					},
 					{
 						"name": "spinbutton",
-						"description": "A form of range that expects the user to select from among discrete choices.\n\nA spinbutton typically allows users to change its displayed value by activating increment and decrement buttons that step through a set of allowed values. Some implementations display the value in an text field that allows editing and typing but typically limits input in ways that help prevent invalid values.\n\nAlthough a spinbutton is similar in appearance to many presentations of select, it is advisable to use spinbutton when working with known ranges (especially in the case of large ranges) as opposed to distinct options. For example, a spinbutton representing a range from 1 to 1,000,000 would provide much better performance than a select widget representing the same values.\n\nAuthors MAY create a spinbutton with children or owned elements, but MUST limit those elements to a textbox and/or two buttons. Alternatively, authors MAY apply the spinbutton role to a text input and create sibling buttons to support the increment and decrement functions.\n\nTo be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus. When a spinbutton receives focus, authors SHOULD ensure focus is placed on the textbox element if one is present, and on the spinbutton itself otherwise. Authors SHOULD also ensure the up and down arrows on a keyboard perform the increment and decrement functions and that the increment and decrement button elements are NOT included in the primary navigation ring, e.g., the Tab ring in HTML.\n\nAuthors SHOULD set the aria-valuenow attribute when the spinbutton has a value. Authors SHOULD set the aria-valuemin attribute when there is a minimum value, and the aria-valuemax attribute when there is a maximum value.",
+						"description": "A form of range that expects the user to select from among discrete choices.\n\nA spinbutton typically allows users to change its displayed value by activating increment and decrement buttons that step through a set of allowed values. Some implementations display the value in an text field that allows editing and typing but typically limits input in ways that help prevent invalid values.\n\nAlthough a spinbutton is similar in appearance to many presentations of select, it is advisable to use spinbutton when working with known ranges (especially in the case of large ranges) as opposed to distinct options. For example, a spinbutton representing a range from 1 to 1,000,000 would provide much better performance than a select widget representing the same values.\n\nAuthors MAY create a spinbutton with accessibility children, but MUST limit those elements to a textbox and/or two buttons. Alternatively, authors MAY apply the spinbutton role to a text input and create sibling buttons to support the increment and decrement functions.\n\nTo be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus. When a spinbutton receives focus, authors SHOULD ensure focus is placed on the textbox element if one is present, and on the spinbutton itself otherwise. Authors SHOULD also ensure the up and down arrows on a keyboard perform the increment and decrement functions and that the increment and decrement button elements are NOT included in the primary navigation ring, e.g., the Tab ring in HTML.\n\nAuthors SHOULD set the aria-valuenow attribute when the spinbutton has a value. Authors SHOULD set the aria-valuemin attribute when there is a minimum value, and the aria-valuemax attribute when there is a maximum value.",
 						"generalization": ["composite", "input", "range"],
 						"requiredContextRole": [],
 						"requiredOwnedElements": [],
@@ -11631,7 +11624,7 @@
 					},
 					{
 						"name": "tab",
-						"description": "A grouping label providing a mechanism for selecting the tab content that is to be rendered to the user.\n\nIf a tabpanel or item in a tabpanel has focus, the associated tab is the currently active tab in the tablist, as defined in Managing Focus. tablist elements, which contain a set of associated tab elements, are typically placed near a series of tabpanel elements, usually preceding it. See the WAI-ARIA Authoring Practices for details on implementing a tab set design pattern.\n\nAuthors MUST ensure elements with role tab are contained in, or owned by, an element with the role tablist.\n\nAuthors SHOULD ensure the tabpanel associated with the currently active tab is perceivable to the user.\n\nFor a single-selectable tablist, authors SHOULD hide from all users other tabpanel elements until the user selects the tab associated with that tabpanel. For a multi-selectable tablist, authors SHOULD ensure that the tab for each visible tabpanel has the aria-expanded attribute set to true, and that the tabs associated with the remaining hidden from all users tabpanel elements have their aria-expanded attributes set to false.\n\nAuthors SHOULD ensure that a selected tab has its aria-selected attribute set to true, that inactive tab elements have their aria-selected attribute set to false, and that the currently selected tab provides a visual indication that it is selected.\n\nIn certain conditions, a user agent MAY provide an implicit value for aria-selected for each tab in a tablist, and if it does, the user agent MUST ensure the following conditions are met before providing an implicit value:",
+						"description": "A grouping label providing a mechanism for selecting the tab content that is to be rendered to the user.\n\nIf a tabpanel or item in a tabpanel has focus, the associated tab is the currently active tab in the tablist, as defined in Managing Focus. tablist elements, which contain a set of associated tab elements, are typically placed near a series of tabpanel elements, usually preceding it. See the WAI-ARIA Authoring Practices for details on implementing a tab set design pattern.\n\nAuthors MUST ensure elements with role tab are accessibility children of an element with the role tablist.\n\nAuthors SHOULD ensure the tabpanel associated with the currently active tab is perceivable to the user.\n\nFor a single-selectable tablist, authors SHOULD hide from all users other tabpanel elements until the user selects the tab associated with that tabpanel. For a multi-selectable tablist, authors SHOULD ensure that the tab for each visible tabpanel has the aria-expanded attribute set to true, and that the tabs associated with the remaining hidden from all users tabpanel elements have their aria-expanded attributes set to false.\n\nAuthors SHOULD ensure that a selected tab has its aria-selected attribute set to true, that inactive tab elements have their aria-selected attribute set to false, and that the currently selected tab provides a visual indication that it is selected.\n\nIn certain conditions, a user agent MAY provide an implicit value for aria-selected for each tab in a tablist, and if it does, the user agent MUST ensure the following conditions are met before providing an implicit value:",
 						"generalization": ["sectionhead", "widget"],
 						"requiredContextRole": ["tablist"],
 						"requiredOwnedElements": [],
@@ -12674,7 +12667,7 @@
 					},
 					{
 						"name": "tooltip",
-						"description": "A contextual popup that displays a description for an element.\n\nThe tooltip typically becomes visible, after a short delay, in response to a mouse hover, or after the owning element receives keyboard focus. The use of a WAI-ARIA tooltip is a supplement to the normal tooltip behavior of the user agent.\n\nTypical tooltip delays last from one to five seconds.\n\nAuthors SHOULD ensure that elements with the role tooltip are referenced through the use of aria-describedby before or at the time the tooltip is displayed.",
+						"description": "A contextual popup that displays a description for an element.\n\nThe tooltip typically becomes visible, after a short delay, in response to a mouse hover, or after the accessibility parent receives keyboard focus. The use of a WAI-ARIA tooltip is a supplement to the normal tooltip behavior of the user agent.\n\nTypical tooltip delays last from one to five seconds.\n\nAuthors SHOULD ensure that elements with the role tooltip are referenced through the use of aria-describedby before or at the time the tooltip is displayed.",
 						"generalization": ["section"],
 						"requiredContextRole": [],
 						"requiredOwnedElements": [],
@@ -12911,7 +12904,7 @@
 					},
 					{
 						"name": "treegrid",
-						"description": "A grid whose rows can be expanded and collapsed in the same manner as for a tree.\n\nIf aria-readonly is set on an element with role treegrid, user agents MUST propagate the value to all gridcell elements owned by the treegrid and expose the value in the accessibility API. An author MAY override the propagated value of aria-readonly for an individual gridcell element.\n\nWhen the aria-readonly attribute is applied to a focusable gridcell, it indicates whether the content contained in the gridcell is editable. The aria-readonly attribute does not represent availability of functions for navigating or manipulating the treegrid itself.\n\nIn a treegrid that provides content editing functions, if the content of a focusable gridcell element is not editable, authors MAY set aria-readonly to true on the gridcell element. However, if a treegrid presents a collection of elements that do not support aria-readonly, such as a collection of link elements, it is not necessary for the author to specify a value for aria-readonly.\n\nTo be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus.",
+						"description": "A grid whose rows can be expanded and collapsed in the same manner as for a tree.\n\nIf aria-readonly is set on an element with role treegrid, user agents MUST propagate the value to all gridcell elements that are accessibility descendants of the treegrid and expose the value in the accessibility API. An author MAY override the propagated value of aria-readonly for an individual gridcell element.\n\nWhen the aria-readonly attribute is applied to a focusable gridcell, it indicates whether the content contained in the gridcell is editable. The aria-readonly attribute does not represent availability of functions for navigating or manipulating the treegrid itself.\n\nIn a treegrid that provides content editing functions, if the content of a focusable gridcell element is not editable, authors MAY set aria-readonly to true on the gridcell element. However, if a treegrid presents a collection of elements that do not support aria-readonly, such as a collection of link elements, it is not necessary for the author to specify a value for aria-readonly.\n\nTo be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus.",
 						"generalization": ["grid", "tree"],
 						"requiredContextRole": [],
 						"requiredOwnedElements": ["caption", "row", "rowgroup > row"],
@@ -13050,7 +13043,7 @@
 					},
 					{
 						"name": "treeitem",
-						"description": "An item in a tree.\n\nA treeitem element can contain a sub-level group of elements that can be expanded or collapsed. An expandable collection of treeitem elements are enclosed in an element with the group role.\n\nAuthors MUST ensure elements with role treeitem are contained in, or owned by, an element with role tree or an element with role group that is contained in, or owned by, an element with role treeitem.\n\nIn certain conditions, a user agent MAY provide an implicit value for aria-selected for each treeitem in a tree, and if it does, the user agent MUST ensure the following conditions are met before providing an implicit value:\n\nIf a user agent provides an implicit aria-selected value for a treeitem, the value SHOULD be true if the treeitem has DOM focus or the tree has DOM focus and the treeitem is referenced by aria-activedescendant. Otherwise, if a user agent provides an implicit aria-selected value for a treeitem, the value SHOULD be false.\n\nAuthors MAY indicate selection for treeitem elements using either aria-selected or aria-checked. Some user interfaces indicate selection with aria-selected in single-select trees and with aria-checked in multi-select trees. Authors SHOULD NOT specify both aria-selected and aria-checked on treeitem elements contained by the same tree except in the extremely rare circumstances where all the following conditions are met:",
+						"description": "An item in a tree.\n\nA treeitem element can contain a sub-level group of elements that can be expanded or collapsed. An expandable collection of treeitem elements are enclosed in an element with the group role.\n\nAuthors MUST ensure elements with role treeitem are accessibility children of an element with role tree or an element with role group that is the accessibility child of an element with role treeitem.\n\nIn certain conditions, a user agent MAY provide an implicit value for aria-selected for each treeitem in a tree, and if it does, the user agent MUST ensure the following conditions are met before providing an implicit value:\n\nIf a user agent provides an implicit aria-selected value for a treeitem, the value SHOULD be true if the treeitem has DOM focus or the tree has DOM focus and the treeitem is referenced by aria-activedescendant. Otherwise, if a user agent provides an implicit aria-selected value for a treeitem, the value SHOULD be false.\n\nAuthors MAY indicate selection for treeitem elements using either aria-selected or aria-checked. Some user interfaces indicate selection with aria-selected in single-select trees and with aria-checked in multi-select trees. Authors SHOULD NOT specify both aria-selected and aria-checked on treeitem elements contained by the same tree except in the extremely rare circumstances where all the following conditions are met:",
 						"generalization": ["listitem", "option"],
 						"requiredContextRole": ["tree", "treeitem > group"],
 						"requiredOwnedElements": [],
@@ -13621,8 +13614,8 @@
 						"enum": [],
 						"defaultValue": "undefined",
 						"valueDescriptions": {
-							"false": "The grouping element this element owns or controls is collapsed.",
-							"true": "The grouping element this element owns or controls is expanded.",
+							"false": "The grouping element this element controls or is the accessibility parent of is collapsed.",
+							"true": "The grouping element this element controls or is the accessibility parent of is expanded.",
 							"undefined": "The element does not own or control a grouping element that is expandable."
 						}
 					},
@@ -37712,7 +37705,7 @@
 					"description": "The height of the frame in CSS pixels. Default is 150."
 				},
 				"loading": {
-					"description": "Indicates how the browser should load the iframe: eager: Load the iframe immediately, regardless if it is outside the visible viewport (this is the default value). lazy: Defer loading of the iframe until it reaches a calculated distance from the viewport, as defined by the browser."
+					"description": "Indicates when the browser should load the iframe: eager Load the iframe immediately on page load (this is the default value). lazy Defer loading of the iframe until it reaches a calculated distance from the visual viewport, as defined by the browser. The intent is to avoid using the network and storage bandwidth required to fetch the frame until the browser is reasonably certain that it will be needed. This improves the performance and cost in most typical use cases, in particular by reducing initial page load times. Note: Loading is only deferred when JavaScript is enabled. This is an anti-tracking measure."
 				},
 				"longdesc": {
 					"description": "A URL of a long description of the frame's content. Due to widespread misuse, this is not helpful for non-visual browsers.",
@@ -37730,7 +37723,7 @@
 					"type": "NavigableTargetName"
 				},
 				"referrerpolicy": {
-					"description": "Indicates which referrer to send when fetching the frame's resource: no-referrer: The Referer header will not be sent. no-referrer-when-downgrade: The Referer header will not be sent to origins without TLS (HTTPS). origin: The sent referrer will be limited to the origin of the referring page: its scheme, host, and port. origin-when-cross-origin: The referrer sent to other origins will be limited to the scheme, the host, and the port. Navigations on the same origin will still include the path. same-origin: A referrer will be sent for same origin, but cross-origin requests will contain no referrer information. strict-origin: Only send the origin of the document as the referrer when the protocol security level stays the same (HTTPS→HTTPS), but don't send it to a less secure destination (HTTPS→HTTP). strict-origin-when-cross-origin (default): Send a full URL when performing a same-origin request, only send the origin when the protocol security level stays the same (HTTPS→HTTPS), and send no header to a less secure destination (HTTPS→HTTP). unsafe-url: The referrer will include the origin and the path (but not the fragment, password, or username). This value is unsafe, because it leaks origins and paths from TLS-protected resources to insecure origins."
+					"description": "Indicates which referrer to send when fetching the frame's resource: no-referrer The Referer header will not be sent. no-referrer-when-downgrade The Referer header will not be sent to origins without TLS (HTTPS). origin The sent referrer will be limited to the origin of the referring page: its scheme, host, and port. origin-when-cross-origin The referrer sent to other origins will be limited to the scheme, the host, and the port. Navigations on the same origin will still include the path. same-origin A referrer will be sent for same origin, but cross-origin requests will contain no referrer information. strict-origin Only send the origin of the document as the referrer when the protocol security level stays the same (HTTPS→HTTPS), but don't send it to a less secure destination (HTTPS→HTTP). strict-origin-when-cross-origin (default) Send a full URL when performing a same-origin request, only send the origin when the protocol security level stays the same (HTTPS→HTTPS), and send no header to a less secure destination (HTTPS→HTTP). unsafe-url The referrer will include the origin and the path (but not the fragment, password, or username). This value is unsafe, because it leaks origins and paths from TLS-protected resources to insecure origins."
 				},
 				"sandbox": {
 					"type": {
@@ -37758,7 +37751,7 @@
 					}
 				},
 				"scrolling": {
-					"description": "Indicates when the browser should provide a scrollbar for the frame: auto: Only when the frame's content is larger than its dimensions. yes: Always show a scrollbar. no: Never show a scrollbar.",
+					"description": "Indicates when the browser should provide a scrollbar for the frame: auto Only when the frame's content is larger than its dimensions. yes Always show a scrollbar. no Never show a scrollbar.",
 					"deprecated": true
 				},
 				"src": {
@@ -40776,7 +40769,7 @@
 		{
 			"name": "source",
 			"cite": "https://developer.mozilla.org/en-US/docs/Web/HTML/Element/source",
-			"description": "The <source> HTML element specifies multiple media resources for the <picture>, the <audio> element, or the <video> element. It is a void element, meaning that it has no content and does not have a closing tag. It is commonly used to offer the same media content in multiple file formats in order to provide compatibility with a broad range of browsers given their differing support for image file formats and media file formats.",
+			"description": "The <source> HTML element specifies one or more media resources for the <picture>, <audio>, and <video> elements. It is a void element, which means that it has no content and does not require a closing tag. This element is commonly used to offer the same media content in multiple file formats in order to provide compatibility with a broad range of browsers given their differing support for image file formats and media file formats.",
 			"categories": [],
 			"contentModel": {
 				"contents": false

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@markuplint/html-spec",
-	"version": "4.0.0-alpha.5",
+	"version": "4.0.0-dev.0+7c596917",
 	"description": "A specification of HTML Living Standard for markuplint",
 	"repository": "git@github.com:markuplint/markuplint.git",
 	"author": "Yusuke Hirao <yusukehirao@me.com>",
@@ -17,11 +17,11 @@
 		"gen:prettier": "prettier --write index.json"
 	},
 	"devDependencies": {
-		"@markuplint/spec-generator": "4.0.0-alpha.5",
-		"@markuplint/test-tools": "4.0.0-alpha.5"
+		"@markuplint/spec-generator": "4.0.0-dev.0+7c596917",
+		"@markuplint/test-tools": "4.0.0-alpha.6"
 	},
 	"dependencies": {
-		"@markuplint/ml-spec": "4.0.0-alpha.5"
+		"@markuplint/ml-spec": "4.0.0-dev.0+7c596917"
 	},
-	"gitHead": "0c3e4690662edf1765bcc4b6411ec5507c1e2ea3"
+	"gitHead": "7c59691701465a0fb3a4b69187318e8033c463d4"
 }