`);
- accordionBody.appendChild(itemCard);
+ elementCardsList.appendChild(itemCard);
});
+ accordionBody.appendChild(elementCardsList);
return accordion;
});
- contentContainer.replaceChildren(contentTitle, ...accordions);
+ contentContainer.replaceChildren(contentTitle, accordionsList);
hljs.highlightAll();
}
@@ -264,53 +260,53 @@ category summary is clicked %>
const whyItMatters = {
accesskeys:
- '\n Specifying a accesskey
attribute value for some part of a\n document allows users to quickly activate or move the focus to a specific\n element by pressing the specified key (usually in combination with the\n alt
key). Duplicating accesskey
values\n creates unexpected effects that ultimately make the page less accessible.\n
\n\n For each defined accesskey
, ensure the value is unique and does\n not conflict with any default browser and screen reader shortcut keys.\n
\n\n Content is not operable by keyboard users with no or low vision who cannot use\n devices such as mice that require eye-hand coordination, users who have\n trouble tracking a pointer, or users who must use alternate keyboards or input\n devices acting as keyboard emulators.\n
',
+ '\n Specifying a accesskey
attribute value for some part of a\n document allows users to quickly activate or move the focus to a specific\n element by pressing the specified key (usually in combination with the\n alt
key). Duplicating accesskey
values\n creates unexpected effects that ultimately make the page less accessible.\n
',
'area-alt':
- '\n Screen readers have no way of translating images into words. It is important\n that all images, including image maps, have alt
text values.\n
\n\n\n Screen readers typically announce the filename of the image if alternative\n text is missing. Filenames do not adequately describe images and are not\n helpful to screen reader users.\n
',
+ '\n Screen readers have no way of translating images into words. It is important\n that all images, including image maps, have alt
text values.\n
',
'aria-allowed-attr':
- '\n Using ARIA attributes in roles where they are not allowed can interfere with\n the accessibility of the web page. Using an invalid role-attribute combination\n will, at best, result in no effect on the accessibility of the application\n and, at worst, may trigger behavior that disables accessibility for entire\n portions of an application.\n
\n\n When ARIA attributes are used on HTML elements that are not in accordance with\n WAI-ARIA 1.1, they conflict with the semantics of the elements which can cause\n assistive technology products report nonsensical user interface (UI)\n information that does not represent the actual UI of the document.\n
',
+ '\n Using ARIA attributes in roles where they are not allowed can interfere with\n the accessibility of the web page. Using an invalid role-attribute combination\n will, at best, result in no effect on the accessibility of the application\n and, at worst, may trigger behavior that disables accessibility for entire\n portions of an application.\n
',
'aria-command-name':
- '\n Screen reader users are not able to discern the purpose of elements with\n role="link"
, role="button"
, or\n role="menuitem"
that do not have an accessible name.\n
',
+ '\n Screen reader users are not able to discern the purpose of elements with\n role="link"
, role="button"
, or\n role="menuitem"
that do not have an accessible name.\n
',
'aria-dialog-name':
- '\n Screen reader users are not able to discern the purpose of elements with\n role="dialog"
or role="alertdialog"
that do not have\n an accessible name.\n
',
+ '\n Screen reader users are not able to discern the purpose of elements with\n role="dialog"
or role="alertdialog"
that do not have\n an accessible name.\n
',
'aria-hidden-focus':
- '\n Using the aria-hidden="true"
attribute on an element removes the\n element and ALL of its child nodes from the accessibility API making it\n completely inaccessible to screen readers and other assistive technologies.\n Aria-hidden may be used with extreme caution to hide visibly rendered content\n from assistive technologies only if the act of hiding this content is intended\n to improve the experience for users of assistive technologies by removing\n redundant or extraneous content. If aria-hidden is used to hide visible\n content from screen readers, the identical or equivalent meaning and\n functionality must be exposed to assistive technologies.\n
\n\n\n Note: Using aria-hidden="false"
on content that\n is a descendent of an element that is hidden using\n aria-hidden="true"
will NOT expose that content to the\n accessibility API and it will not be accessible to screen readers or other\n assistive technologies.\n
\n\n\n The rule applies to any element with an\n aria-hidden="true"
attribute.\n
\n\n\n By adding aria-hidden="true"
to an element, content authors\n ensure that assistive technologies will ignore the element. This can be used\n to hide decorative parts of a web page, such as icon fonts - that are not\n meant to be read by assistive technologies.\n
\n\n\n A focusable element with aria-hidden="true"
is ignored as part of\n the reading order, but still part of the focus order, making it’s state of\n visible or hidden unclear.\n
\n\n',
+ '\n Using the aria-hidden="true"
attribute on an element removes the\n element and ALL of its child nodes from the accessibility API making it\n completely inaccessible to screen readers and other assistive technologies.\n Aria-hidden may be used with extreme caution to hide visibly rendered content\n from assistive technologies only if the act of hiding this content is intended\n to improve the experience for users of assistive technologies by removing\n redundant or extraneous content. If aria-hidden is used to hide visible\n content from screen readers, the identical or equivalent meaning and\n functionality must be exposed to assistive technologies.\n
',
'aria-input-field-name':
'\n This new rule ensures every ARIA input field has an accessible name.\n Accessible names must exist for the following input field roles:\n
\n\n - combobox
\n - listbox
\n - searchbox
\n - slider
\n - spinbutton
\n - textbox
\n
',
'aria-meter-name':
- '\n Screen reader users are not able to discern the purpose of elements with\n role="meter"
that do not have an accessible name.\n
',
+ '\n Screen reader users are not able to discern the purpose of elements with\n role="meter"
that do not have an accessible name.\n
',
'aria-progressbar-name':
- '\n Screen reader users are not able to discern the purpose of elements with\n role="progressbar"
that do not have an accessible name.\n
',
+ '\n Screen reader users are not able to discern the purpose of elements with\n role="progressbar"
that do not have an accessible name.\n
',
'aria-required-children':
- '\n For each role, WAI-ARIA explicitly defines which child and parent roles are\n allowable and/or required. ARIA role
s missing required child\n role
s will not be able to perform the accessibility functions\n intended by the developer.\n
\n\n Assistive technology needs to convey the context to the user. For example, in\n a treeitem
, it is important to know the parent (container), item,\n or siblings in the folder. This can be done in two ways:\n
\n\n - \n Code order or DOM: The necessary context is often clear\n from the code order or DOM.\n
\n - \n ARIA: ARIA (such as
aria-owns
) can be used\n provide the relationships when the hierarchy is not the same as the code\n structure or DOM tree.\n \n
',
+ '\n For each role, WAI-ARIA explicitly defines which child and parent roles are\n allowable and/or required. ARIA role
s missing required child\n role
s will not be able to perform the accessibility functions\n intended by the developer.\n
',
'aria-required-parent':
- '\n For each role, WAI-ARIA explicitly defines which child and parent roles are\n allowable and/or required. Elements containing ARIA role
values\n missing required parent element role
values will not enable\n assistive technology to function as intended by the developer.\n
\n\n When it is necessary to convey context to the user of assistive technology in\n the form of hierarchy (for example, the importance of a parent container, item\n or sibling in a folder tree), and the hierarchy is not the same as the code\n structure or DOM tree, there is no way to provide the relationship information\n without the use of ARIA role parent elements.\n
',
+ '\n For each role, WAI-ARIA explicitly defines which child and parent roles are\n allowable and/or required. Elements containing ARIA role
values\n missing required parent element role
values will not enable\n assistive technology to function as intended by the developer.\n
',
'aria-roledescription':
- "\n Inappropriate aria-roledescription
attribute values that conflict\n with an element's implied or explicit role
value can interfere\n with the accessibility of the web page. A conflicting\n aria-roledescription
attribute value may result in no effect on\n the accessibility of the application and may trigger behavior that disables\n accessibility for entire portions of an application.\n
\n\n When aria-roledescription
> attributes are applied to HTML\n elements not in accordance with WAI-ARIA 1.1, semantics conflict between the\n aria-roledescription
value and the implicit or explicit element\n role
value which may result in assistive technology products\n reporting nonsensical user interface (UI) information that does not correctly\n represent the intended UI experience.\n
",
+ '\n Inappropriate aria-roledescription
attribute values that conflict\n with an element's implied or explicit role
value can interfere\n with the accessibility of the web page. A conflicting\n aria-roledescription
attribute value may result in no effect on\n the accessibility of the application and may trigger behavior that disables\n accessibility for entire portions of an application.\n
',
'aria-text':
- '\n When a text node is split by markup (e.g.\n <h1>Hello <span>World</span></h1>
)\n VoiceOver will treat it as two separate phrases instead of just one. Adding\n role="text"
around the elements solves the problem. However, it\n also overrides the role of the element and all descendants and treats them all\n as text nodes. If one of the descendant elements is also focusable it would\n create an empty tab stop. That is, you could tab to the element but VoiceOver\n would not announce its name, role, or value.\n
',
+ '\n When a text node is split by markup (e.g.\n <h1>Hello <span>World</span></h1>
)\n VoiceOver will treat it as two separate phrases instead of just one. Adding\n role="text"
around the elements solves the problem. However, it\n also overrides the role of the element and all descendants and treats them all\n as text nodes. If one of the descendant elements is also focusable it would\n create an empty tab stop. That is, you could tab to the element but VoiceOver\n would not announce its name, role, or value.\n
',
'aria-toggle-field-name':
'\n Ensures every element with a semantic role also has an accessible name.\n Semantic roles include:\n
\n\n - checkbox
\n - menu
\n - menuitemcheckbox
\n - menuitemradio
\n - radio
\n - radiogroup
\n - switch
\n
',
'aria-tooltip-name':
- '\n Screen reader users are not able to discern the purpose of elements with\n role="tooltip"
that do not have an accessible name.\n
',
+ '\n Screen reader users are not able to discern the purpose of elements with\n role="tooltip"
that do not have an accessible name.\n
',
'aria-treeitem-name':
- '\n Screen reader users are not able to discern the purpose of elements with\n role="treeitem"
that do not have an accessible name.\n
',
+ '\n Screen reader users are not able to discern the purpose of elements with\n role="treeitem"
that do not have an accessible name.\n
',
'aria-valid-attr-value':
- '\n ARIA attributes (i.e. starting with aria-
) must contain valid\n values. These values must be spelled correctly and correspond to values that\n make sense for a particular attribute to perform the intended accessibility\n function.\n
\n\n\n Many ARIA attributes accept a specific set of values. Allowed values,\n acceptable "undefined" values, and acceptable "default" values are required.\n Failure to comply with allowed values results in content that is not\n accessible to assistive technology users.\n
',
+ '\n ARIA attributes (i.e. starting with aria-
) must contain valid\n values. These values must be spelled correctly and correspond to values that\n make sense for a particular attribute to perform the intended accessibility\n function.\n
',
'aria-valid-attr':
- '\n If the developer uses a non-existent or misspelled ARIA attribute, the\n attribute will not be able to perform the accessibility function intended by\n the developer.\n
\n\n In order to allow assistive technologies to convey appropriate information to\n persons with disabilities, user interface elements intended to improve the\n accessibility and interoperability of web and application content must conform\n to properly spelled and current ARIA attributes.\n
\n\n When developers do not use attributes defined in the WAI-ARIA 1.1 W3C\n Recommendation, they do not properly convey user interface behaviors and\n structural information to assistive technologies in document-level markup.\n
',
+ '\n If the developer uses a non-existent or misspelled ARIA attribute, the\n attribute will not be able to perform the accessibility function intended by\n the developer.\n
',
'autocomplete-valid':
'\n Failure to provide autocomplete values in form fields results in inaccessible\n content. Screen readers do not read identified autocomplete form fields if the\n appropriate autocomplete attribute values are missing. Users cannot correctly\n navigate forms when screen readers cannot provide adequate information to the\n user regarding form field interaction requirements.\n
',
'avoid-inline-spacing':
'\n Many people with cognitive disabilities have trouble tracking lines of text\n when a block of text is single spaced. Providing spacing between 1.5 to 2\n allows them to start a new line more easily once they have finished the\n previous one.\n
',
blink:
- '\n As the name suggests, blink
tags cause content to flash. Though\n you may like the effect, blinking text can be difficult to read, and blinking\n objects (links, buttons, etc.) can be difficult to activate, especially for\n users with imprecise or limited dexterity.\n
\n\n It can be very difficult for people with visual and cognitive disabilities to\n see and understand text that blinks. Blinking text be distracting, especially\n for users with cognitive disabilities. It can also be difficult for some\n individuals to comprehend. For these reasons, the blink
element\n should never be used.\n
',
+ '\n As the name suggests, blink
tags cause content to flash. Though\n you may like the effect, blinking text can be difficult to read, and blinking\n objects (links, buttons, etc.) can be difficult to activate, especially for\n users with imprecise or limited dexterity.\n
',
'definition-list':
- '\n Screen readers have a specific way of announcing definition lists. When such\n lists are not properly marked up, this creates the opportunity for confusing\n or inaccurate screen reader output.\n
\n\n A definition list is used to provide the definitions of words or phrases. The\n Definition List is marked up using the dl
element. Within the\n list, each term is put in a separate dt
element, and its\n definition goes in the dd
element directly following it.\n
',
+ '\n Screen readers have a specific way of announcing definition lists. When such\n lists are not properly marked up, this creates the opportunity for confusing\n or inaccurate screen reader output.\n
',
dlitem:
- "\n A definition list item must be wrapped in parent dl
elements,\n otherwise it will be invalid.\n
\n\n A definition list must follow a specific hierarchy. A list is defined using\n the dl
element. What follows are alternating sets of\n dt
and dd
elements, starting with the\n dt
element. dt
elements define a term while\n dd
elements denote a term's description. Each set of\n dt
elements must have a corresponding set of\n dd
elements. Only dt
and dd
elements\n are allowed in definition list. If this hierarchy is not followed, the list\n will be invalid.\n
",
+ '\n A definition list item must be wrapped in parent dl
elements,\n otherwise it will be invalid.\n
',
'duplicate-id-active':
- '\n The ID attribute uniquely identifies focusable elements on a page. It does not\n make sense to duplicate an active ID.\n
\n\n\n Duplicate active ID values break the accessibility of focusable elements\n including labels for forms, table header cells, etc., Screen readers and\n client-side scripts will skip any duplication other than the first instance.\n Validating HTML files help prevent and eliminate possible sources of\n accessibility problems, when not breaking accessibility.\n
\n\n\n Those experienced with client-side scripting know that when you re-use an\n active ID, typically the only one that gets acted upon by the scripting is the\n first instance of the use of that active ID. Similarly, assistive technologies\n may, when referencing an active ID, only reference the first one accurately.\n
',
+ '\n The ID attribute uniquely identifies focusable elements on a page. It does not\n make sense to duplicate an active ID.\n
',
'empty-table-header':
'\n Table header elements should have visible text that describes the purpose of\n the row or column to both sighted users and screen reader users.\n
',
'frame-focusable-content':
@@ -318,123 +314,123 @@ category summary is clicked %>
'frame-tested':
'\n Without the axe-core script, it is not possible for the tool to perform\n violation checking on multiple levels of nested iframes.\n
',
'frame-title-unique':
- '\n Screen reader users rely on a frame title to describe the contents of the\n frame
. Navigating through frames and iframes can quickly become\n difficult and confusing for users of this technology if the frames are not\n marked with a title
attribute.\n
\n\n\n Screen reader users have the option to pull up a list of titles for all frames\n on a page. Adding descriptive, unique titles allows users to quickly find the\n frame they need. If no titles are present, navigating through frames can\n quickly become difficult and confusing. If no title is listed, screen readers\n will instead give information like “frame,” “javascript,” the filename, or the\n URL. In most cases, this information won’t be very helpful.\n
',
+ '\n Screen reader users rely on a frame title to describe the contents of the\n frame
. Navigating through frames and iframes can quickly become\n difficult and confusing for users of this technology if the frames are not\n marked with a title
attribute.\n
',
'frame-title':
- '\n Screen reader users rely on a frame title to describe the contents of the\n frame
. Navigating through frame
and\n iframe
elements quickly becomes difficult and confusing for users\n of this technology if the markup does not contain a\n title
attribute.\n
\n\n\n Screen reader users have the option to pull up a list of titles for all frames\n on a page. Adding descriptive, unique titles allows users to quickly find the\n frame they need. If no titles are present, navigating through frames can\n quickly become difficult and confusing. If no title is listed, screen readers\n will instead give information like “frame,” “JavaScript,” the filename, or the\n URL. In most cases, this information won’t be very helpful.\n
',
+ '\n Screen reader users rely on a frame title to describe the contents of the\n frame
. Navigating through frame
and\n iframe
elements quickly becomes difficult and confusing for users\n of this technology if the markup does not contain a\n title
attribute.\n
',
'html-xml-lang-mismatch':
- "\n When configuring a screen reader, users select a default language. If the\n language of a webpage is not specified, the screen reader assumes the default\n language set by the user. Multiple languages are an issue for users who speak\n and access websites in multiple languages. It is essential to specify a\n default language and ensure that it is valid for screen readers to function\n correctly.\n
\n\n Screen readers use different sound libraries for each language, based on the\n pronunciation and characteristics of that language. Screen readers can switch\n between language libraries easily, but only if documents specify which\n language(s) should to read. If the language is not specified, screen readers\n read documents in the user's default language, resulting in garbled language.\n It can be challenging to understand anything when screen readers are using the\n wrong language library.\n
",
+ '\n When configuring a screen reader, users select a default language. If the\n language of a webpage is not specified, the screen reader assumes the default\n language set by the user. Multiple languages are an issue for users who speak\n and access websites in multiple languages. It is essential to specify a\n default language and ensure that it is valid for screen readers to function\n correctly.\n
',
'image-alt':
- "\n Screen readers have no way of translating an image into words that gets read\n to the user, even if the image only consists of text. As a result, it's\n necessary for images to have short, descriptive alt
text so\n screen reader users clearly understand the image's contents and purpose.\n
\n\n If you can't see, all types of visual information, such as images, are\n completely useless unless a digital text alternative is provided so that\n screen readers can convert that text into either sound or braille. The same is\n true in varying degrees for people with low vision or color-blindness.\n
",
+ '\n Screen readers have no way of translating an image into words that gets read\n to the user, even if the image only consists of text. As a result, it's\n necessary for images to have short, descriptive alt
text so\n screen reader users clearly understand the image's contents and purpose.\n
',
'image-redundant-alt':
- '\n It is unnecessary and potentially confusing to have alternative text for a\n link or image to be repeated in text adjacent to the link or image since it\n would be read twice by a screen reader.\n
\n\n\n Since image buttons use alt attributes for labels, the labels must not\n duplicate the text next to the button. Duplicated alternative text for an\n image or link in the text adjacent to that image or link results in screen\n readers announcing the text to the user twice.\n
',
+ '\n It is unnecessary and potentially confusing to have alternative text for a\n link or image to be repeated in text adjacent to the link or image since it\n would be read twice by a screen reader.\n
',
'input-button-name':
- '\n Screen reader users are not able to discern the purpose of an\n input type="button"
without an accessible name.\n
\n\n Screen reader users cannot understand the purpose of an image without a\n discernable and accessible textual name. A title for an image may provide only\n advisory information about the image itself. Unnamed actionable graphic images\n such as buttons have no clear description of the destination, purpose,\n function or action for the non-text content when it is intended to be used as\n a control.\n
',
+ '\n Screen reader users are not able to discern the purpose of an\n input type="button"
without an accessible name.\n
',
'input-image-alt':
- '\n An <input type="image">
button must have\n alternate text, otherwise screen reader users will not know the button\'s\n purpose. Even if the image contains only text, it still requires alternate\n text, since a screen reader cannot translate images of words into output.\n
\n\n\n Text Alone Is Not A Label: Just typing text next to the form\n element is not sufficient to create a true label. Assistive technologies like\n screen readers require labels in code that can be determined programmatically.\n Some screen readers are programmed to guess what the label should be, based on\n the surrounding text, but this method is not fool-proof and can lead to\n confusion if the screen reader guesses wrong.\n
',
+ '\n An <input type="image">
button must have\n alternate text, otherwise screen reader users will not know the button's\n purpose. Even if the image contains only text, it still requires alternate\n text, since a screen reader cannot translate images of words into output.\n
',
'landmark-banner-is-top-level':
- '\n If the banner landmark is not the top-level landmark (and is contained within\n another landmark), it does not effectively designate the pre-defined header\n portion of the layout in the design and therefore prevents screen reader users\n from being able to easily find their way around the layout.\n
\n\n\n
Note
\n
\n Landmarks are used to designate sections of the overall page design and\n layout. Headings are used to designate sections within the content.\n
\n
',
+ '\n If the banner landmark is not the top-level landmark (and is contained within\n another landmark), it does not effectively designate the pre-defined header\n portion of the layout in the design and therefore prevents screen reader users\n from being able to easily find their way around the layout.\n
',
'landmark-complementary-is-top-level':
'\n Complementary content is ancillary content to the main theme of a document or\n page. Screen reader users have the option to skip over complementary content\n when it appears at the top level of the accessibility API. Embedding an\n <aside>
element in another landmark may disable screen\n reader functionality allowing users to navigate through complementary content.\n
',
'landmark-contentinfo-is-top-level':
- "\n The purpose of the contentinfo
landmark can be defeated when\n placed within another landmark, as it can prevent blind screen reader users\n from being able to quickly find and navigate to the appropriate landmark.\n
\n\n\n When screen reader users have to sort through too much extra information to\n find what they're looking for, such as not being able to quickly figure out\n which landmark contains the content information they're looking for negates\n the purpose of an existing contentinfo
landmark.\n
",
+ '\n The purpose of the contentinfo
landmark can be defeated when\n placed within another landmark, as it can prevent blind screen reader users\n from being able to quickly find and navigate to the appropriate landmark.\n
',
'landmark-main-is-top-level':
- '\n Navigating a web page is far simpler for screen reader users if the content\n splits between some high-level sections. Content outside of these sections is\n difficult to find, and its purpose may be unclear.\n
\n\n\n HTML has historically lacked some key semantic markers, such as the ability to\n designate sections of the page as the header, navigation, main content, and\n footer. Using both HTML5 elements and ARIA landmarks in the same element is\n considered a best practice, but the future probably favors HTML regions as\n browser support increases.\n
\n\n\n The HTML Living Standard states "A hierarchically correct main element is one\n whose ancestor elements are limited to <html>,\n <body>, <div>,\n <form without an accessible name, and autonomous custom\n elements. Each main element must be a hierarchically correct main element."\n This may reflect a "best practice" based on W3C validation.\n
',
+ '\n Navigating a web page is far simpler for screen reader users if the content\n splits between some high-level sections. Content outside of these sections is\n difficult to find, and its purpose may be unclear.\n
',
'landmark-no-duplicate-banner':
- '\n Landmarks allow blind users to navigate and find content quickly. Missing\n landmarks require screen reader users to sort through too much extra\n information to find anything.\n
\n\n JAWS, NVDA, and VoiceOver support the ability to navigate to sections of a web\n page using ARIA landmarks. Landmarks provide a more elegant solution to the\n problem of providing a way for users to skip to the main content of the web\n page. There is no visible alteration to the web design, making it unobtrusive\n and invisible. Of course, the fact that this technique is invisible is fine\n for blind screen reader users, but not so fine for sighted keyboard users or\n screen enlarger users with low vision. In this sense, HTML 5 regions and ARIA\n landmarks cannot yet replace the old-fashioned "skip navigation" links.\n Browsers still do not have a built-in way to notify users that HTML 5 regions\n or ARIA landmarks are present. Screen reader users are the only ones who can\n take advantage of them. There is a\n Firefox ARIA landmark extension\n \n available, which adds the ability to navigate by landmarks in Firefox, but\n this is not a native feature of the browser.\n
',
+ '\n Landmarks allow blind users to navigate and find content quickly. Missing\n landmarks require screen reader users to sort through too much extra\n information to find anything.\n
',
'landmark-no-duplicate-contentinfo':
- '\n One of the main purposes of landmarks is to allow blind users to quickly find\n and navigate to the appropriate landmark, so you should keep the total number\n of landmarks relatively low. If you don\'t, screen reader users will have to\n sort through too much extra information to find what they\'re looking for.\n
\n\n Despite all of the talk about using correct semantic structure for\n accessibility, HTML has historically lacked some key semantic markers, such as\n the ability to designate sections of the page as the header, navigation, main\n content, and footer. With HTML5, these designations are possible, using the\n new elements header
, nav
, main
, and\n footer
. Similar functionality is available using the ARIA\n (Accessible Rich Internet Application) attributes role="banner"
,\n role="navigation"
, role="main"
and\n role="contentinfo"
.\n
\n\n\n JAWS, NVDA, and VoiceOver support the ability to navigate to sections of a web\n page using ARIA landmarks. Landmarks provide a more elegant solution to the\n problem of providing a way for users to skip to the main content of the web\n page. There is no visible alteration to the web design, making it unobtrusive\n and invisible. Of course, the fact that this technique is invisible is fine\n for blind screen reader users, but not so fine for sighted keyboard users or\n screen enlarger users with low vision. In this sense, HTML 5 regions and ARIA\n landmarks cannot yet replace the old-fashioned "skip navigation" links.\n Browsers still do not have a built-in way to notify users that HTML 5 regions\n or ARIA landmarks are present. Screen reader users are the only ones who can\n take advantage of them. There is a\n Firefox ARIA landmark extension\n \n available, which adds the ability to navigate by landmarks in Firefox, but\n this is not a native feature of the browser.\n
',
+ '\n One of the main purposes of landmarks is to allow blind users to quickly find\n and navigate to the appropriate landmark, so you should keep the total number\n of landmarks relatively low. If you don't, screen reader users will have to\n sort through too much extra information to find what they're looking for.\n
',
'landmark-no-duplicate-main':
- '\n Navigating a web page is far simpler for screen reader users if all of the\n content splits between one or more high-level sections. Content outside of\n these sections is difficult to find, and its purpose may be unclear.\n
\n\n\n HTML has historically lacked some key semantic markers, such as the ability to\n designate sections of the page as the header, navigation, main content, and\n footer. Using both HTML5 elements and ARIA landmarks in the same element is\n considered a best practice, but the future will favor HTML regions as browser\n support increases.\n
',
+ '\n Navigating a web page is far simpler for screen reader users if all of the\n content splits between one or more high-level sections. Content outside of\n these sections is difficult to find, and its purpose may be unclear.\n
',
'landmark-unique':
'\n landmark-unique
is a new best practice rule ensures that\n landmarks have a unique role or accessible name (i.e. role, label, title)\n combination.\n
',
- list: '\n Screen readers have a specific way of announcing lists. This feature makes\n lists clearer to understand, but will only work if lists are properly\n structured.\n
\n\n When content elements other than list items are contained within a set of list\n elements, screen readers cannot inform the listener that they are listening to\n items within the list.\n
\n\n For a list to be valid, it must have both parent elements (a set of\n ul
elements or a set of ol
elements) and child\n elements (declared inside of these tags using the li
element),\n and any other content elements are invalid.\n
\n\n Although some non-content elements such as script, template, style,\n meta, link, map, area, and datalist are permitted within lists,\n content elements other than li
are not permitted.\n
',
+ list: '\n Screen readers have a specific way of announcing lists. This feature makes\n lists clearer to understand, but will only work if lists are properly\n structured.\n
',
listitem:
- "\n For a list to be valid, it must have both parent and child elements. Parent\n elements can either be a set of ul
tags or a set of\n ol
tags. Child elements must be declared inside of these tags\n using the li
tag.\n
\n\n\n Screen readers notify users when they come to a list, and tell them how many\n items are in a list. Announcing the number of items in a list and the current\n list item helps listeners know what they are listening to, and what to expect\n as they listen to it.\n
\n\n\n If you don't mark up a list using proper semantic markup in a hierarchy, list\n items cannot inform the listener that they are listening to a list when no\n parent is indicating the presence of a list and the type of list.\n
",
+ '\n For a list to be valid, it must have both parent and child elements. Parent\n elements can either be a set of ul
tags or a set of\n ol
tags. Child elements must be declared inside of these tags\n using the li
tag.\n
',
marquee:
- '\n The marquee
element creates scrolling text that is difficult to\n read and click on. Beyond that, it can be distracting to viewers, especially\n to those with low vision, cognitive disabilities, or attention deficits.\n
\n\n People with attention deficits or cognitive disabilities could become\n distracted by content that scrolls. If scrolling content contains links,\n people with limited fine motor abilities may not be able to click on the links\n accurately. Users with visual impairments may not be able to see the scrolling\n text with enough acuity to know what the content says.\n
',
+ '\n The marquee
element creates scrolling text that is difficult to\n read and click on. Beyond that, it can be distracting to viewers, especially\n to those with low vision, cognitive disabilities, or attention deficits.\n
',
'meta-refresh':
- '\n Since users do not expect a page to refresh automatically, such refreshing can\n be disorienting. Refreshing also moves the programmatic focus back to the top\n of the page, away from where the user had it. Such resetting is frustrating\n for users.\n
\n\n Redirection and page refresh through the use of the\n <meta>
element is problematic for users with disabilities\n in many ways. The primary reason why redirects and refreshes are problematic\n is that the user has no control over when the redirect or refresh occurs. If\n the purpose of the <meta>
element is to redirect the user\n to a new location, server-side means should be employed instead of\n client-side. Content that moves or auto-updates can be a barrier to anyone who\n has trouble reading the stationary text as quickly as well as to anyone who\n has trouble tracking moving objects. It can also cause problems for screen\n readers.\n
',
+ '\n Since users do not expect a page to refresh automatically, such refreshing can\n be disorienting. Refreshing also moves the programmatic focus back to the top\n of the page, away from where the user had it. Such resetting is frustrating\n for users.\n
',
'object-alt':
- '\n Screen readers have no way of translating non-text content into text announced\n to users. Instead, they read out alternative text. For screen reader users to\n obtain the information contained in embedded object
elements\n which must contain short, descriptive alternative text.\n
\n\n\n The object
element defines an embedded object within a document.\n It is used to embed multimedia (audio, video, applets, etcetera.) or another\n web page into the document. The object element needs a text alternative so\n that users of screen readers know the contents of the object.\n
\n\n When writing a text alternative, keep in mind that the purpose of the\n alternative text is to relay information to blind users about the image’s\n contents and purpose - blind users should be able to get as much information\n from alternative text as a sighted user gets from the image. Alternative text\n should give the intent, purpose, and meaning of the image.\n
\n\n When writing alternative text, it’s helpful to keep the following questions in\n mind:\n
\n\n - Why is the non-text content here?
\n - What information is it presenting?
\n - What purpose does it fulfill?
\n - \n If I could not use the non-text content, what words would I use to convey\n the same information or function?\n
\n
\n\n\n Be sure that all text contained in this attribute is useful. Words like\n “chart”, “image”, “diagram”, or image file names tend not to be very useful.\n
',
+ '\n Screen readers have no way of translating non-text content into text announced\n to users. Instead, they read out alternative text. For screen reader users to\n obtain the information contained in embedded object
elements\n which must contain short, descriptive alternative text.\n
',
'presentation-role-conflict':
- '\n There are certain cases where the semantic role of an element with\n role="none"
or role="presentation"
does not resolve\n to none or presentation (respectively). When this happens, the element is not\n removed from the accessibility tree (as expected) and screen readers are able\n to interact with it.\n
\n\n To ensure the element remains removed from the accessibility tree, you should\n not add any global ARIA attributes to the element or make if focusable.\n
',
+ '\n There are certain cases where the semantic role of an element with\n role="none"
or role="presentation"
does not resolve\n to none or presentation (respectively). When this happens, the element is not\n removed from the accessibility tree (as expected) and screen readers are able\n to interact with it.\n
',
'role-img-alt':
- "\n Screen readers have no way of translating an image into words that gets read\n to the user, even if the image only consists of text. As a result, it's\n necessary for images to have short, descriptive and accessible alternative\n text so screen reader users clearly understand the image's contents and\n purpose.\n
\n\n If you can't see, all types of visual information, including images, are\n completely useless unless an accessible text alternative is provided which\n screen readers can convert into either sound or braille. People with low\n vision or color-blindness disabilities also require accessible alternative\n text to varying degrees.\n
\n\n Screen readers cannot convert visual image information to speech or braille in\n the absence of an accessible text alternative associated with the image.\n
",
+ '\n Screen readers have no way of translating an image into words that gets read\n to the user, even if the image only consists of text. As a result, it's\n necessary for images to have short, descriptive and accessible alternative\n text so screen reader users clearly understand the image's contents and\n purpose.\n
',
'scope-attr-valid':
- '\n The scope
attribute makes table navigation much easier for screen\n reader users, provided that it is used correctly. Incorrectly used,\n scope
can make table navigation much harder and less efficient.\n
\n\n\n A screen reader operates under the assumption that a table has a header and\n that this header specifies a scope. Because of the way screen readers\n function, having an accurate header makes viewing a table far more accessible\n and more efficient for people who use the device.\n
',
+ '\n The scope
attribute makes table navigation much easier for screen\n reader users, provided that it is used correctly. Incorrectly used,\n scope
can make table navigation much harder and less efficient.\n
',
'scrollable-region-focusable':
'\n Checks scrollable content for focusable elements enabling keyboard navigation.\n Keyboard navigation should not fail when focus moves to an element within a\n scrollable region.\n
',
'select-name':
- '\n Effective form labels are required to make forms accessible. The purpose of\n form elements such as checkboxes, radio buttons, input fields, etcetera, is\n often apparent to sighted users, even if the form element is not\n programmatically labeled. Screen readers users require useful form labels to\n identify form fields. Adding a label to all form elements eliminates ambiguity\n and contributes to a more accessible product.\n
\n\n When labels for form elements are absent, screen reader users do not know the\n input data expectations. Screen readers cannot programmatically determine\n information about input objects without an established label relationship (or\n redundant text serving as a label).\n
',
+ '\n Effective form labels are required to make forms accessible. The purpose of\n form elements such as checkboxes, radio buttons, input fields, etcetera, is\n often apparent to sighted users, even if the form element is not\n programmatically labeled. Screen readers users require useful form labels to\n identify form fields. Adding a label to all form elements eliminates ambiguity\n and contributes to a more accessible product.\n
',
'server-side-image-map':
- '\n Server-side image maps are not keyboard accessible; mouse clicks are required\n to access the links contained in the image, making the image inaccessible to\n people who only use keyboards for their navigation.\n
\n\n\n Server side image maps pass the coordinates of the mouse click to the\n server-side script used to process the image map. Because they rely on mouse\n clicks, they are not keyboard accessible, whereas client-side image maps are\n keyboard accessible. Further, it is not possible to provide text alternatives\n to the actionable areas of a server-side image map like you can with the\n area
s of a client-side image map.\n
',
+ '\n Server-side image maps are not keyboard accessible; mouse clicks are required\n to access the links contained in the image, making the image inaccessible to\n people who only use keyboards for their navigation.\n
',
'skip-link':
'\n Screen readers announce content sequentially as it appears in the HTML file.\n What this means for users of assistive technology is that the content at the\n top of the page, typically including the entire navigation, is read out to the\n user before reaching any of the main content. Since content at the top of the\n page can often be very lengthy, it can be time-consuming to listen to or tab\n through all of it when the user is only interested in the main content.\n Including a skip link in an HTML page is beneficial to blind users, users with\n low vision, and mouse-only users.\n
',
'svg-img-alt':
- '\n The intent of\n Success Criterion 1.1.1\n is to make information conveyed by non-text content (including SVG images)\n accessible through the use of a text alternative. Text alternatives are a\n primary way for making information accessible because they can be rendered\n through any sensory modality (for example, visual, auditory or tactile) to\n match the needs of the user. Providing text alternatives allows the\n information to be rendered in a variety of ways by a variety of user agents.\n For example, a person who cannot see a picture can have the text alternative\n read aloud using synthesized speech. A person who cannot hear an audio file\n can have the text alternative displayed so that he or she can read it. In the\n future, text alternatives will also allow information to be more easily\n translated into sign language or into a simpler form of the same language.\n
',
+ "\n If you can't see, images are completely useless without a digital text alternative. The same is true in varying degrees for people with low vision or colour-blindness. \n
",
tabindex:
- '\n Using tabindex
with a value greater than 0 can create as many\n problems as it solves. It creates an unexpected tab order, which makes the\n page less intuitive and can give the appearance of skipping certain elements\n entirely.\n
\n\n\n Here are some of the problems that tabindex
(with a value of 1 or\n greater) causes:\n
\n\n - \n Unexpected tab order: From the perspective of the user,\n
tabindex
changes the default tab order in unexpected ways,\n possibly causing disorientation.\n \n - \n Items can appear to be skipped entirely: Items appear in\n the tab order only once. If a user tabs past the
tabindex
items\n and continues through the rest of the web page, at some point the user\n arrives at the location of the tabindex
items, but the tabbing\n process skips over these links, because the user already tabbed through them\n at the beginning of the cycle. Incorrect tab orders are frustrating when\n users are unable access items, and may not know that (s)he needs to cycle\n through the entire set of links on the page to reaccess those links.\n \n - \n All
tabindex
items are tabbed to before any non-tabindex
\n items.\n If you want to change the tab order of the first items AND of a section\n later in the page, you would need to set the tabindex
value for\n every single item through to the end of the modified section. Taken to a bit\n of an extreme, if you have 20 links on a page, and if you set the\n tabindex
of one of those links to tabindex="100"
,\n the user tabs to that link first, even though there are fewer than 100 links\n on the page. There is no way to modify the tab order of sections later in\n the page unless you manually set the tab order of all the links before that\n section.\n \n
',
+ '\n Using tabindex
with a value greater than 0 can create as many\n problems as it solves. It creates an unexpected tab order, which makes the\n page less intuitive and can give the appearance of skipping certain elements\n entirely.\n
',
'table-duplicate-name':
- '\n Screen readers have a specific way of announcing tables. When tables are not\n properly marked up, this creates the opportunity for confusing or inaccurate\n screen reader output.\n
\n\n When tables have summary and caption text that is identical, screen reader\n users can be confused and find it difficult to know the name and purpose of\n the table.\n
',
+ '\n When tables have summary and caption text that is identical, screen reader\n users can be confused and find it difficult to know the name and purpose of\n the table.\n
',
'td-headers-attr':
- "\n Screen readers have a specific way of announcing tables. When tables are not\n properly marked up, this creates the opportunity for confusing or inaccurate\n screen reader output.\n
\n\n Sighted users can usually tell at a glance what the table's headers are and\n what their relationship to the data is. For non-sighted users this must be\n done in the markup.\n
\n\n\n When a data table is designed with accessibility in mind, the user enters into\n table navigation mode, which allows the user to navigate from cell to cell\n within the table while hearing the screen reader announce the corresponding\n table headers for the data cells. Hearing the table headers is especially\n helpful when navigating through large data tables, or when cells contain\n similar-sounding data that could be easily confused.\n
\n\n\n Table navigation mode is not useful, though, if the table lacks accessibility\n features.\n
",
+ "\n Sighted users can usually tell at a glance what the table's headers are and\n what their relationship to the data is. For non-sighted users this must be\n done in the markup.\n
",
'th-has-data-cells':
- '\n Screen readers have a specific way of announcing tables. When tables are not\n properly marked up, this creates the opportunity for confusing or inaccurate\n screen reader output.\n
\n\n When tables are not marked up semantically and do not have the correct header\n structure, screen reader users cannot correctly perceive the relationships\n between the cells and their contents visually.\n
',
+ '\n When tables are not marked up semantically and do not have the correct header\n structure, screen reader users cannot correctly perceive the relationships\n between the cells and their contents visually.\n
',
'valid-lang':
- "\n When configuring a screen reader, users select a default language. If the\n language of a webpage is not specified, the screen reader assumes it is the\n default language set by the user. Language selection becomes an issue for\n users who speak multiple languages and access the website in more than one\n language. It is essential to specify a language and ensure that it is valid so\n website text is pronounced correctly.\n
\n\n Screen readers use different sound libraries for each language, based on the\n pronunciation and characteristics of that language. Screen readers can switch\n between these language libraries easily, but only if the documents specify\n which language(s) to read. If the language is not specified, the screen reader\n reads the document in the user's default language, resulting in a confusing\n experience!\n
",
+ '\n When configuring a screen reader, users select a default language. If the\n language of a webpage is not specified, the screen reader assumes it is the\n default language set by the user. Language selection becomes an issue for\n users who speak multiple languages and access the website in more than one\n language. It is essential to specify a language and ensure that it is valid so\n website text is pronounced correctly.\n
',
'video-caption':
- '\n If a video has no caption, deaf users have limited or no access to the\n information contained in it. Even if a captions track is available, ensure\n that it contains all meaningful information in the video, not just dialogue.\n
\n\n Deaf viewers can see everything in the video but are not able to hear any of\n it without captions. Without a caption track, deaf viewers do not have a way\n of knowing the dialog, narration, or the essential sounds not spoken by\n people, such as "dramatic instrumental music," applause, screams, or other\n sounds that set the scene, provide context, or give meaning to the video.\n
',
+ '\n If a video has no caption, deaf users have limited or no access to the\n information contained in it. Even if a captions track is available, ensure\n that it contains all meaningful information in the video, not just dialogue.\n
',
'no-autoplay-audio':
- '\n People who are blind or have low vision and use screen reading software can\n find it hard to hear the screen reader\'s speech output if there is other audio\n playing at the same time. If automatically playing audio lasts more than three\n seconds, an easily located, accessible mechanism must be provided to pause or\n stop the audio or control the audio volume. An audio control allows screen\n reader users to hear the screen reader without other sounds playing.\n
\n\n\n
Note:
\n
\n Playing audio automatically when landing on a page may affect a screen\n reader user\'s ability to find the mechanism to stop it because they navigate\n by listening and automatically started sounds might interfere with that\n navigation. Therefore, we discourage the practice of automatically starting\n sounds (especially if they last more than three seconds), and encourage that\n the sound be started by an action initiated by the user after they reach the\n page, rather than requiring that the sound be stopped by an action of the\n user after they land on the page.\n
\n
',
+ '\n People who are blind or have low vision and use screen reading software can\n find it hard to hear the screen reader's speech output if there is other audio\n playing at the same time. If automatically playing audio lasts more than three\n seconds, an easily located, accessible mechanism must be provided to pause or\n stop the audio or control the audio volume. An audio control allows screen\n reader users to hear the screen reader without other sounds playing.\n
',
'aria-hidden-body':
- '\n When <body aria-hidden="true"
, content is not\n accessible to assistive technology.\n
\n\n Applying aria-hidden="true"
to otherwise accessible objects: A\n web page is designed to be fully accessible, and it would be accessible if\n elements do not contain the\n aria-hidden="true"
attribute value. Screen readers do\n not read content marked with the\n aria-hidden="true"
attribute value. Users can still tab\n to focusable elements in the hidden objects, but screen readers remain silent.\n
\n\n Any content or interface elements intentionally hidden from users — e.g.,\n inactive dialogs, collapsed menus — must also be hidden from screen reader\n users. When items are available to sighted users — such as when they activate\n a button or expand a menu item — the same items must be available to screen\n reader users. The goal is to provide screen reader users an equivalent user\n experience to sighted users. If there is a compelling reason to hide content\n from sighted users, there is usually a compelling reason also to hide that\n content from blind users. Further, when content is made available to sighted\n users, it makes sense to make it available to blind users as well.\n
',
+ '\n Screen readers do not read content marked with the aria-hidden="true"
attribute value. Users can still tab to focusable elements in the hidden objects, but screen readers remain silent.\n
',
'aria-required-attr':
- "\n ARIA widget roles require additional attributes that describe the state of the\n widget. The state of the widget is not communicated to screen reader users if\n a required attribute is omitted.\n
\n\n\n Certain roles act as composite user interface widgets. As such, they typically\n act as containers that manage other, contained widgets. When an object\n inherits from multiple ancestors and one ancestor indicates support for one\n property while another ancestor indicates that the same property is required,\n the property becomes required on the inheriting object. In some cases, default\n values are sufficient to meet ARIA attribute requirements.\n
\n\n\n When required state and property attributes for specific roles (and subclass\n roles) are not present, screen readers may not be able to convey the\n definition of what the element's role is to the users.\n
",
+ '\n ARIA widget roles require additional attributes that describe the state of the\n widget. The state of the widget is not communicated to screen reader users if\n a required attribute is omitted.\n
',
bypass:
- '\n Since web sites often display secondary, repeated content on multiple pages\n (such as navigation links, heading graphics, and advertising frames),\n keyboard-only users benefit from faster, more direct access to the primary\n content on a page. This reduces keystrokes and minimizes associated physical\n pain.\n
\n\n\n For users who cannot use a mouse, navigating with a keyboard is more difficult\n and time-consuming when the interface does not include methods to make\n keyboard navigation easier. For example, to activate a link in the middle of a\n web page, a keyboard user may have to tab through a large number of links and\n buttons in the header and main navigation of the page.\n
\n\n\n At the extreme end, users with severe motor limitations might require several\n minutes to tab through all of those elements, and can lead to fatigue and\n possible physical pain for some users. Even users with less severe constraints\n will require longer than mouse users, who can click on the desired link in a\n second or two.\n
',
+ '\n Since web sites often display secondary, repeated content on multiple pages\n (such as navigation links, heading graphics, and advertising frames),\n keyboard-only users benefit from faster, more direct access to the primary\n content on a page. This reduces keystrokes and minimizes associated physical\n pain.\n
',
'color-contrast':
- "\n Some people with low vision experience low contrast, meaning that there aren't\n very many bright or dark areas. Everything tends to appear about the same\n brightness, which makes it hard to distinguish outlines, borders, edges, and\n details. Text that is too close in luminance (brightness) to the background\n can be hard to read.\n
\n\n There are nearly three times more individuals with low vision than those with\n total blindness. One in twelve people cannot see the average full spectrum of\n colors - about 8% of men and 0.4% of women in the US. A person with low vision\n or color blindness is unable to distinguish text against a background without\n sufficient contrast.\n
\nColor transparency and opacity is taken into account in the background.
\n\n Color transparency and opacity in the foreground is more difficult to detect\n and account for due to:\n
\n\n - 1:1 colors in foreground and background.
\n - CSS background gradients.
\n - Background colors in CSS pseudo-elements.
\n - Background colors created with CSS borders.
\n - \n Overlap by another element in the foreground - this sometimes comes up with\n tricky positioning.\n
\n - Elements moved outside the viewport via CSS.
\n
",
+ '\n Some people with low vision experience low contrast, meaning that there aren't\n very many bright or dark areas. Everything tends to appear about the same\n brightness, which makes it hard to distinguish outlines, borders, edges, and\n details. Text that is too close in luminance (brightness) to the background\n can be hard to read.\n
',
'document-title':
- '\n Screen reader users use page titles to get an overview of the contents of the\n page. Navigating through pages can quickly become difficult and confusing for\n screen reader users if the pages are not marked with a title. The page\n title
element is the first thing screen reader users hear when\n first loading a web page.\n
\n\n\n The title
is the first thing that screen reader users hear when\n they arrive at a page. If there is no title
or if the\n title
is not descriptive and unique, screen reader users must\n read through the page to determine its contents and purpose.\n
',
+ '\n Screen reader users use page titles to get an overview of the contents of the\n page. Navigating through pages can quickly become difficult and confusing for\n screen reader users if the pages are not marked with a title. The page\n title
element is the first thing screen reader users hear when\n first loading a web page.\n
',
'duplicate-id-aria':
- "\n Duplicate IDs are common validation errors that may break the accessibility of\n labels, e.g., ARIA elements, form fields, table header cells.\n
\n\n Unique ID's differentiate each element from another and prevent invalid\n markup, wherein only the first instance gets acted upon by client-side\n scripting, or where assistive technologies typically only reference the first\n one accurately.\n
",
+ '\n Duplicate IDs are common validation errors that may break the accessibility of\n labels, e.g., ARIA elements, form fields, table header cells.\n
',
'duplicate-id':
- "\n The ID attribute uniquely identifies elements on a page. It does not make\n sense to duplicate an ID.\n
\n\n\n Duplicate ID's can break the accessibility of labels for forms, table header\n cells, etc., by the second instance being skipped by screen readers, or by\n client-side scripts. They are common markup validation errors that can\n eliminate possible sources of accessibility problems, when not breaking\n accessibility.\n
\n\n\n Those experienced with client-side scripting know that when you re-use an id,\n typically the only one that gets acted upon by the scripting is the first\n instance of the use of that ID. Similarly, assistive technologies may, when\n referencing an id, only reference the first one accurately.\n
",
+ "\n The ID attribute uniquely identifies elements on a page. It does not make\n sense to duplicate an ID.\n
\n\n\n Duplicate ID's can break the accessibility of labels for forms, table header\n cells, etc., by the second instance being skipped by screen readers, or by\n client-side scripts. They are common markup validation errors that can\n eliminate possible sources of accessibility problems, when not breaking\n accessibility.\n
",
'empty-heading':
- "\n Screen readers alert users to the presence of a heading tag. If the heading is\n empty or the text cannot be accessed, this could either confuse users or even\n prevent them from accessing information on the page's structure.\n
\n\n\n If the text inside a heading cannot be accessed by a screen reader, users of\n this technology will not be able to hear the contents of the heading. Since\n headings relay the structure of a webpage, it's crucial that users of screen\n readers are able to access the contents.\n
\n\n Applying heading markup (<h1>
through\n ><h6>
) is a quick way to make text stand out, however,\n using it for anything other than headings will make navigating a web page more\n confusing for users of assistive technology.\n
\n\n In addition to making the page more accessible, headings have other benefits,\n since search engines use headings when filtering, ordering, and displaying\n results. Improving the accessibility of your site can also have the effect of\n making your page more findable.\n
\n\n In the same way that sighted users can glance at a page and get a sense of its\n contents, users of screen readers can do the same by navigating through\n headings. Well written and properly ordered headings can save users,\n especially those who use screen readers, a lot of time and frustration.\n
",
+ '\n Screen readers alert users to the presence of a heading tag. If the heading is\n empty or the text cannot be accessed, this could either confuse users or even\n prevent them from accessing information on the page's structure.\n
',
'form-field-multiple-labels':
'\n Assigning multiple labels to the same form field can cause problems for some\n combinations of screen readers and browsers, and the results are inconsistent\n from one combination to the next. Some combinations will read the first label.\n Some will read the last label. Others will read both labels.\n
',
'heading-order':
- '\n The underlying purpose of headers is to convey the structure of the page. For\n sighted users, the same purpose is achieved using different sizes of text.\n Text size, however, is not helpful for users of screen readers, because a\n screen reader identifies a header only if it is properly marked-up. When\n heading elements are applied correctly, the page becomes much easier to\n navigate for screen reader users and sighted users alike.\n
\n\n\n In the same way that sighted users can glance at a page and get a sense of its\n contents, users of screen readers can do the same by navigating through\n headings. Well written and properly ordered headings can save users,\n especially those who use screen readers, a lot of time and frustration.\n
\n\n\n The purpose of headings is to describe the structure of the webpage, not just\n highlight important text. They should be brief, clear, unique, and marked with\n h1
through h6
elements applied in hierarchical\n order. All of these qualities make headings valuable tools for screen reader\n users. Similar to the way sighted users can glance at a page and get a sense\n of its contents, screen reader users can navigate through headings. Well\n written and properly ordered headings can save screen reader time and\n frustration.\n
\n\n\n In addition to making the page more accessible, headings have other benefits\n since search engines use headings when filtering, ordering, and displaying\n results. Improving the accessibility of your site can also have the effect of\n making your page more findable.\n
',
+ '\n The underlying purpose of headers is to convey the structure of the page. For\n sighted users, the same purpose is achieved using different sizes of text.\n Text size, however, is not helpful for users of screen readers, because a\n screen reader identifies a header only if it is properly marked-up. When\n heading elements are applied correctly, the page becomes much easier to\n navigate for screen reader users and sighted users alike.\n
',
'html-has-lang':
- "\n When configuring a screen reader, users select a default language. If the\n language of a webpage is not specified, the screen reader assumes the default\n language set by the user. Language settings become an issue for users who\n speak multiple languages and access website in more than one language. It is\n essential to specify a language and ensure that it is valid so website text is\n pronounced correctly.\n
\n\n Screen readers use different sound libraries for each language, based on the\n pronunciation and characteristics of that language. Screen readers can switch\n between these language libraries easily, but only if the documents specify\n which language(s) to read and when. If the language is not specified, the\n screen reader reads the document in the user's default language, resulting in\n a strange accent! It is impossible to understand anything when screen readers\n are using the wrong language library.\n
",
+ '\n When configuring a screen reader, users select a default language. If the\n language of a webpage is not specified, the screen reader assumes the default\n language set by the user. Language settings become an issue for users who\n speak multiple languages and access website in more than one language. It is\n essential to specify a language and ensure that it is valid so website text is\n pronounced correctly.\n
',
'html-lang-valid':
- "\n When configuring a screen reader, users select a default language. If the\n language of a webpage is not specified, the screen reader assumes the default\n language set by the user. Language settings are an issue for users who speak\n multiple languages and access website in more than one language. It is\n essential to specify a language and ensure that it is valid so website text is\n pronounced correctly.\n
\n\n Screen readers use different sound libraries for each language, based on the\n pronunciation and characteristics of that language. Screen readers can switch\n between these language libraries easily, but only if the documents correctly\n specify which language(s) to read. If the language is not specified, the\n screen reader reads the document in the user's default language, resulting in\n a confusing accent! It is impossible to understand anything when screen\n readers are using the wrong language library.\n
",
+ '\n When configuring a screen reader, users select a default language. If the\n language of a webpage is not specified, the screen reader assumes the default\n language set by the user. Language settings are an issue for users who speak\n multiple languages and access website in more than one language. It is\n essential to specify a language and ensure that it is valid so website text is\n pronounced correctly.\n
',
'label-title-only':
- '\n The title
and aria-describedby
attributes are used\n to provide additional information such as a hint. Hints are exposed to\n accessibility APIs differently than labels and as such, this can cause\n problems with assistive technologies.\n
\n\n\n When form inputs such as text entry fields, radio buttons, check boxes, and\n select menus contain no labels other than title
and\n aria-describedby
attribute values, screen readers interpret the\n content as advisory information only. Labels created by the\n title
and aria-describedby
values are not sufficient\n to create a true label that can be determined programmatically from the code\n to convey the purpose of the input form element.\n
',
+ '\n The title
and aria-describedby
attributes are used\n to provide additional information such as a hint. Hints are exposed to\n accessibility APIs differently than labels and as such, this can cause\n problems with assistive technologies.\n
',
'link-in-text-block':
- "\n Some people with low vision experience low contrast, meaning that there aren't\n very many bright or dark areas. Everything tends to appear about the same\n brightness, which makes it hard to distinguish outlines, borders, edges, and\n details. Text that is too close in luminance (brightness) to the background\n can be hard to read.\n
\n\n There are nearly three times more individuals with low vision than those with\n total blindness. One person in twelve has a color deficiency - about 8% of men\n and 0.4% of women in the US. A person with low vision or color blindness is\n unable to distinguish text against a background without sufficient contrast.\n
\n\n When a sufficient color contrast ratio of 3:1 is not present to distinguish\n link text color from surrounding text color, users with low vision who\n experience low contrast cannot detect visually that the text is intended to\n function as a link.\n
",
+ '\n Some people with low vision experience low contrast, meaning that there aren't\n very many bright or dark areas. Everything tends to appear about the same\n brightness, which makes it hard to distinguish outlines, borders, edges, and\n details. Text that is too close in luminance (brightness) to the background\n can be hard to read.\n
',
'link-name':
- '\n - \n
\n Inaccessible link elements pose barriers to accessibility, as they are a\n fundamental component of a website.\n
\n \n - \n
\n Users who rely exclusively on a keyboard (and no mouse) to navigate a\n webpage can only click on links that can receive programmatic focus. A\n link that cannot receive programmatic focus is inaccessible to these\n users.\n
\n \n\n - \n
\n Like sighted users, screen reader users need to know where a link is\n pointing. Inner link text provides this information, though it won\'t get\n used if a screen reader can\'t access it.\n
\n \n\n - \n
\n Keyboard users, including visually impaired screen reader users or people\n who cannot use a mouse, can activate only the links and form elements that\n can receive programmatic focus. Any events activated exclusively by other\n types of focus, for example onmouseover
events that depend on\n the mouse hover focus, are inaccessible to keyboard users. Only links and\n form elements receive keyboard focus by default. Modify elements that are\n not links or form components to receive focus by adding\n tabindex="0"
.\n
\n \n
',
+ '\n Inaccessible link elements pose barriers to accessibility, as they are a fundamental component of a website.\n
',
'meta-viewport-large':
- '\n The user-scalable="no"
parameter inside the\n content
attribute of\n <meta name="viewport">
element disables zooming on a page.\n The maximum-scale
parameter limits the amount the user can zoom.\n This is problematic for people with low vision who rely on screen magnifiers\n to properly see the contents of a web page.\n
\n\n\n Users with partial vision and low vision often choose to enlarge the fonts on\n their browser to make text on the web easier to read. The browser\'s viewport\n focus is everything visible in the browser window at a given moment. If the\n user maximizes the browser to full size on a high-resolution monitor, the\n viewport focus area is large and may include the entire web page.\n
\n\n If the browser window is small, the viewport focus area includes only a small\n part of the web page. The browser\'s viewport focus does not affect the\n programmatic focus. Users can scroll up and down the web page, but the\n programmatic focus does not follow the viewport. The Web Content Accessibility\n Guidelines calls for developers to design pages so that they support resize up\n to 200%; however, it is a best practice to require 5x zoom.\n
',
+ '\n The user-scalable="no"
parameter inside the\n content
attribute of\n <meta name="viewport">
element disables zooming on a page.\n The maximum-scale
parameter limits the amount the user can zoom.\n This is problematic for people with low vision who rely on screen magnifiers\n to properly see the contents of a web page.\n
',
'meta-viewport':
- '\n The user-scalable="no"
parameter inside the\n content
attribute of\n <meta name="viewport">
element disables zooming on a page.\n The maximum-scale
parameter limits the amount the user can zoom.\n This is problematic for people with low vision who rely on screen magnifiers\n to properly see the contents of a web page.\n
\n\n\n Users with partial vision and low vision often choose to enlarge the fonts on\n their browser to make text on the web easier to read. The browser\'s viewport\n focus is everything visible in the browser window at a given moment.\n Maximizing the browser to full size on a high-resolution monitor creates a\n large the viewport focus area and may include the entire web page.\n
\n\n If the browser window is small, the viewport focus area only includes a small\n part of the web page. The browser\'s viewport focus does not affect the\n programmatic focus. Users can scroll up and down the web page, but the\n programmatic focus does not follow the viewport. The Web Content Accessibility\n Guidelines calls for developers to design pages so that they support resize up\n to 200%.\n
\n\n Ensures that the user-scalable="no"
parameter is not present in\n the <meta name="viewport">
element and the\n maximum-scale
parameter is not less than 2.\n
',
+ '\n The user-scalable="no"
parameter inside the\n content
attribute of\n <meta name="viewport">
element disables zooming on a page.\n The maximum-scale
parameter limits the amount the user can zoom.\n This is problematic for people with low vision who rely on screen magnifiers\n to properly see the contents of a web page.\n
',
'nested-interactive':
'\n Focusable elements with an interactive control ancestor (any element that\n accepts user input such as button or anchor elements) are not announced by\n screen readers and create an empty tab stop. That is, you could tab to the\n element but the screen reader will not announce its name, role, or state.\n
',
'page-has-heading-one':
- "\n Screen reader users can use keyboard shortcuts to navigate directly to the\n first h1
, which, in principle, should allow them to jump directly\n to the main content of the web page. If there is no h1
, or if the\n h1
appears somewhere other than at the start of the main content,\n screen reader users must listen to more of the web page to understand its\n structure, wasting valuable time.\n
\n\n\n Keep in mind that blind users can't just look at a web page and immediately\n understand its layout the way that a visual user can. Visual users can take in\n much information about the page layout without having to read all of the\n content. Blind users don't have that luxury. Screen readers read linearly,\n which means listening to the entire web page unless there is some other\n convenient way to get a \"glimpse\" of the page's layout and structure. It turns\n out that headings are a way to do that. Screen reader users can use keyboard\n shortcuts to navigate through the heading structure of a document.\n
",
+ '\n Screen reader users can use keyboard shortcuts to navigate directly to the\n first h1
, which, in principle, should allow them to jump directly\n to the main content of the web page. If there is no h1
, or if the\n h1
appears somewhere other than at the start of the main content,\n screen reader users must listen to more of the web page to understand its\n structure, wasting valuable time.\n
',
region:
- "\n Navigating a web page is far simpler for screen reader users if the content\n splits between multiple high-level sections. Content outside of sections is\n difficult to find, and the content's purpose may be unclear.\n
\n\n\n Historically, HTML lacked some key semantic markers such as the ability to\n designate sections of the page as the header, navigation, main content, and\n footer. Using both HTML5 elements and ARIA landmarks in the same element is\n considered a best practice, but the future favors using native HTML5 element\n regions as browser support increases.\n
",
+ '\n Navigating a web page is far simpler for screen reader users if the content\n splits between multiple high-level sections. Content outside of sections is\n difficult to find, and the content's purpose may be unclear.\n
',
'button-name':
- '\n Screen reader users are not able to discern the purpose of elements with\n role="link"
, role="button"
, or\n role="menuitem"
that do not have an accessible name.\n
',
+ '\n Screen reader users are not able to discern the purpose of elements with\n role="link"
, role="button"
, or\n role="menuitem"
that do not have an accessible name.\n
',
'aria-allowed-role':
- '\n Intended accessible technology behavior by a developer is not enabled when an\n assigned WAI-ARIA role value is invalid for the parent element.\n
\n\n When screen readers and other assistive technologies do not know the role of\n each element on the web page, they are not able to interact with it\n intelligently, nor are they able to communicate the role to the user. When the\n value for a role is invalid, there is no way to communicate the element\'s\n features, properties, and methods to assistive technologies. For example,\n applying role="table"
to a <ul>
effectively\n hijacks the default semantics associated with the\n <ul>
element in a way that screenreaders do not expect\n resulting in unexpected behavior.\n
',
+ '\n Intended accessible technology behavior by a developer is not enabled when an\n assigned WAI-ARIA role value is invalid for the parent element.\n
',
'aria-roles':
- "\n Elements assigned invalid ARIA role values are not interpreted by assistive\n technology as intended by the developer.\n
\n\n When screen readers and other assistive technologies do not know the role of\n each element on the web page, they are not able to interact with it\n intelligently, nor are they able to communicate the role to the user. An\n element's features, properties, and methods of conveying information to and/or\n from the user can't be communicated via assistive technologies when a role\n value is invalid.\n
",
+ '\n Elements assigned invalid ARIA role values are not interpreted by assistive\n technology as intended by the developer.\n
',
label:
- '\n Effective form labels are required to make forms accessible. The purpose of\n form elements such as checkboxes, radio buttons, input fields, etcetera, is\n often apparent to sighted users, even if the form element is not\n programmatically labeled. Screen readers users require useful form labels to\n identify form fields. Adding a label to all form elements eliminates ambiguity\n and contributes to a more accessible product.\n
\n\n When labels for form elements are absent, screen reader users do not know the\n input data expectations. Screen readers cannot programmatically determine\n information about input objects without an established label relationship (or\n redundant text serving as a label).\n
\n\n The absence of labels prevent fields from receiving focus when read by screen\n readers, and users with impaired motor control do not get the benefit of a\n larger clickable area for the control since clicking the label activates the\n control.\n
',
+ '\n Effective form labels are required to make forms accessible. The purpose of\n form elements such as checkboxes, radio buttons, input fields, etcetera, is\n often apparent to sighted users, even if the form element is not\n programmatically labeled. Screen readers users require useful form labels to\n identify form fields. Adding a label to all form elements eliminates ambiguity\n and contributes to a more accessible product.\n
',
'landmark-one-main':
- '\n Navigating a web page is far simpler for screen reader users if all of the\n content splits between one or more high-level sections. Content outside of\n these sections is difficult to find, and its purpose may be unclear.\n
\n\n\n HTML has historically lacked some key semantic markers, such as the ability to\n designate sections of the page as the header, navigation, main content, and\n footer. Using both HTML5 elements and ARIA landmarks in the same element is\n considered a best practice, but the future will favor HTML regions as browser\n support increases.\n
',
+ '\n Navigating a web page is far simpler for screen reader users if all of the\n content splits between one or more high-level sections. Content outside of\n these sections is difficult to find, and its purpose may be unclear.\n
',
};
diff --git a/static/ejs/partials/styles/styles.ejs b/static/ejs/partials/styles/styles.ejs
index fba357f5..05e41f2d 100644
--- a/static/ejs/partials/styles/styles.ejs
+++ b/static/ejs/partials/styles/styles.ejs
@@ -61,7 +61,7 @@
font-size: 1.125rem;
font-weight: 700;
margin-top: 0;
- margin-bottom: 1rem;
+ margin-bottom: 1.5rem;
line-height: 2rem;
}
#accessibility-site-report p {
@@ -91,13 +91,13 @@
a[target='_blank']:after {
content: url("data:image/svg+xml,%3Csvg width='12' height='12' viewBox='0 0 12 12' fill='none' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath fill-rule='evenodd' clip-rule='evenodd' d='M6.477 2.625C6.477 2.52554 6.43749 2.43016 6.36716 2.35984C6.29684 2.28951 6.20146 2.25 6.102 2.25H1.125C0.826631 2.25 0.540483 2.36853 0.329505 2.5795C0.118526 2.79048 0 3.07663 0 3.375L0 10.875C0 11.1734 0.118526 11.4595 0.329505 11.6705C0.540483 11.8815 0.826631 12 1.125 12H8.625C8.92337 12 9.20952 11.8815 9.42049 11.6705C9.63147 11.4595 9.75 11.1734 9.75 10.875V5.898C9.75 5.79854 9.71049 5.70316 9.64016 5.63283C9.56984 5.56251 9.47446 5.523 9.375 5.523C9.27554 5.523 9.18016 5.56251 9.10983 5.63283C9.03951 5.70316 9 5.79854 9 5.898V10.875C9 10.9745 8.96049 11.0698 8.89016 11.1402C8.81984 11.2105 8.72446 11.25 8.625 11.25H1.125C1.02554 11.25 0.930161 11.2105 0.859835 11.1402C0.789509 11.0698 0.75 10.9745 0.75 10.875V3.375C0.75 3.27554 0.789509 3.18016 0.859835 3.10984C0.930161 3.03951 1.02554 3 1.125 3H6.102C6.20146 3 6.29684 2.96049 6.36716 2.89016C6.43749 2.81984 6.477 2.72446 6.477 2.625Z' fill='%230047FA'/%3E%3Cpath fill-rule='evenodd' clip-rule='evenodd' d='M12 0.375C12 0.275544 11.9605 0.180161 11.8902 0.109835C11.8198 0.0395088 11.7245 0 11.625 0L7.875 0C7.77554 0 7.68016 0.0395088 7.60983 0.109835C7.53951 0.180161 7.5 0.275544 7.5 0.375C7.5 0.474456 7.53951 0.569839 7.60983 0.640165C7.68016 0.710491 7.77554 0.75 7.875 0.75H10.7197L4.6095 6.8595C4.57463 6.89437 4.54697 6.93576 4.5281 6.98131C4.50924 7.02687 4.49952 7.07569 4.49952 7.125C4.49952 7.17431 4.50924 7.22313 4.5281 7.26869C4.54697 7.31424 4.57463 7.35563 4.6095 7.3905C4.64436 7.42537 4.68576 7.45302 4.73131 7.47189C4.77686 7.49076 4.82569 7.50047 4.875 7.50047C4.92431 7.50047 4.97313 7.49076 5.01869 7.47189C5.06424 7.45302 5.10563 7.42537 5.1405 7.3905L11.25 1.28025V4.125C11.25 4.22446 11.2895 4.31984 11.3598 4.39016C11.4302 4.46049 11.5255 4.5 11.625 4.5C11.7245 4.5 11.8198 4.46049 11.8902 4.39016C11.9605 4.31984 12 4.22446 12 4.125V0.375Z' fill='%230047FA'/%3E%3C/svg%3E%0A");
display: inline-block;
- padding-left: 0.5rem;
+ padding-left: 0.25rem;
text-decoration-line: none;
}
- /* hr {
- border-color: #b5c5ca !important;
- opacity: 1 !important;
- } */
+ .unbulleted-list {
+ list-style: none;
+ padding-left: 0;
+ }
#header .card {
box-shadow: 0 3px 5px 0 #736ccb1a;
}
@@ -367,6 +367,11 @@
#wcagLinksList li {
margin-bottom: 0.5rem;
}
+ #top-five-card li:not(:last-of-type) {
+ border-bottom: 1px solid #b5c5ca;
+ padding-bottom: 0.5rem;
+ margin-bottom: 0.5rem;
+ }
.category-selector {
border: 1px solid #b5c5ca;
background-color: white;
@@ -377,22 +382,20 @@
display: flex;
flex-direction: column;
}
- .category-selector:focus {
- outline: none;
- }
.category-selector.selected {
border: 2px solid #0047fa;
padding: calc(1rem - 1px);
cursor: default;
}
- .category-selector:not(.selected):focus,
.category-selector:not(.selected):hover {
cursor: pointer;
background-color: #f2f6ff;
border: 1px solid #0047fa;
}
- .category-selector h3 {
+ .category-selector .category-name {
+ font-weight: bold;
font-size: 1.125rem;
+ line-height: 2rem;
}
.category-selector .category-name::before {
height: 1.25rem;
@@ -415,21 +418,24 @@
.category-selector.passed .category-name::before {
background-image: var(--passed-icon);
}
- .category-selector span {
+ .category-selector .category-information {
color: #4a6168;
text-align: start;
}
#scan-about {
width: 300px;
padding: 1.5rem 1rem;
- overflow-wrap: anywhere;
+ word-break: break-all;
+ }
+ #scan-about ul {
+ padding-left: 0;
}
- #scan-about > div {
+ #scan-about li {
display: flex;
align-items: center;
margin-bottom: 1rem;
}
- #scan-about > div > svg {
+ #scan-about li > svg {
flex-shrink: 0;
margin-right: 1rem;
height: 1.125rem;
@@ -441,6 +447,29 @@
font-size: 0.875rem;
line-height: 1rem;
}
+ #empty-category-summary-section {
+ padding-top: 1.5rem;
+ width: 100%;
+ text-align: center;
+ }
+ #empty-category-summary-section p {
+ color: #4A6168;
+ }
+ #no-issues-message {
+ display: flex;
+ align-items: center;
+ justify-content: center;
+ }
+ #no-issues-message::before {
+ content: '';
+ display: inline-block;
+ width: 1.75rem;
+ height: 1.75rem;
+ background-image: url("data:image/svg+xml,%3Csvg width='28' height='28' viewBox='0 0 28 28' fill='none' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath d='M14.8408 3.56156C13.5637 3.24229 12.3775 4.20812 12.292 5.4585C12.1958 6.8625 11.9847 8.15161 11.7202 8.9184C11.5532 9.39932 11.0803 10.2716 10.3309 11.1079C9.58682 11.9401 8.61832 12.6816 7.48416 12.9915C6.58646 13.2359 5.67139 14.0134 5.67139 15.1489V20.4937C5.67139 21.6225 6.58245 22.4494 7.60573 22.5576C9.03511 22.7099 9.69503 23.112 10.3683 23.5235L10.4324 23.5636C10.7958 23.784 11.2046 24.0284 11.7282 24.2101C12.2586 24.3918 12.8784 24.5 13.6866 24.5H18.3622C19.6139 24.5 20.4982 23.8628 20.9457 23.0786C21.162 22.7086 21.2789 22.2889 21.285 21.8603C21.285 21.6573 21.2543 21.4435 21.1822 21.2405C21.4507 20.8891 21.6898 20.4683 21.8341 20.0369C21.981 19.596 22.0639 19.0189 21.8394 18.5019C21.9316 18.3283 21.9997 18.1426 22.0518 17.9636C22.1547 17.6029 22.2028 17.2048 22.2028 16.8187C22.2028 16.434 22.1547 16.0373 22.0518 15.6752C22.0051 15.5088 21.9434 15.347 21.8675 15.1917C22.1014 14.8589 22.2519 14.4747 22.3063 14.0716C22.3607 13.6684 22.3174 13.2582 22.1801 12.8753C21.9049 12.0844 21.269 11.4058 20.577 11.176C19.4455 10.7993 18.1685 10.8073 17.216 10.8942C17.0182 10.9119 16.8209 10.9342 16.6242 10.961C17.0876 8.97636 17.0592 6.90861 16.5414 4.93751C16.4513 4.62169 16.2785 4.33568 16.0408 4.10904C15.8031 3.8824 15.5092 3.72337 15.1895 3.64839L14.8408 3.56156ZM18.3622 23.1655H13.6866C13.0053 23.1655 12.5338 23.0733 12.1637 22.9464C11.7883 22.8168 11.4878 22.6418 11.1271 22.4214L11.0736 22.3893C10.3322 21.9365 9.47327 21.4128 7.74733 21.2298C7.30248 21.1817 7.00726 20.8424 7.00726 20.4951V15.1489C7.00726 14.8096 7.30916 14.4235 7.8355 14.2806C9.29828 13.8798 10.4765 12.9501 11.3275 11.9989C12.1757 11.0505 12.7488 10.0285 12.9813 9.35657C13.3059 8.42146 13.525 6.99475 13.6252 5.54934C13.6586 5.06575 14.1061 4.75583 14.5162 4.85736L14.8662 4.94552C15.0799 4.99896 15.2108 5.13655 15.2509 5.28617C15.7965 7.36481 15.7292 9.55688 15.0572 11.5982C15.0192 11.7117 15.0124 11.8334 15.0375 11.9504C15.0626 12.0675 15.1187 12.1757 15.2 12.2636C15.2812 12.3516 15.3846 12.416 15.4993 12.4503C15.614 12.4846 15.7359 12.4874 15.8521 12.4585L15.8561 12.4571L15.8748 12.4531L15.9522 12.4344C16.4091 12.3374 16.8712 12.2674 17.3362 12.2247C18.2219 12.1445 19.2826 12.1525 20.1549 12.4438C20.3887 12.5212 20.756 12.8445 20.9163 13.3121C21.0593 13.7235 21.0326 14.2071 20.561 14.6773L20.0894 15.1489L20.561 15.6218C20.6184 15.6792 20.7013 15.8102 20.7667 16.0426C20.8308 16.2657 20.8669 16.5369 20.8669 16.8187C20.8669 17.1019 20.8308 17.3718 20.7667 17.5962C20.6999 17.8287 20.6184 17.9596 20.561 18.017L20.0894 18.4886L20.561 18.9615C20.6238 19.0243 20.7066 19.1979 20.5677 19.6134C20.4229 20.0163 20.1928 20.3831 19.8931 20.6888L19.4215 21.1603L19.8931 21.6332C19.9011 21.6399 19.9478 21.7 19.9478 21.8603C19.9419 22.0563 19.8863 22.2475 19.7862 22.416C19.5658 22.8008 19.1143 23.1641 18.3622 23.1641V23.1655Z' fill='%234A6168'/%3E%3C/svg%3E%0A");
+ background-repeat: no-repeat;
+ background-size: auto;
+ margin-right: 0.5rem;
+ }
.rule-item {
display: flex;
align-items: center;
@@ -479,66 +508,21 @@
width: 55%;
overflow-y: auto;
}
- #expandedRuleName {
+ #expandedRule #expandedRuleName {
font-size: 1.5rem;
font-weight: bold;
line-height: 2rem;
+ margin-bottom: 0;
}
-
#expandedRuleDescription {
- position: relative;
- }
-
- #expandedRuleDescription.collapse::after {
- content: '';
- position: absolute;
- z-index: 1;
- bottom: 0;
- left: 0;
- pointer-events: none;
- background-image: linear-gradient(
- to bottom,
- rgba(255, 255, 255, 0),
- rgba(255, 255, 255, 1) 80%
- );
- width: 100%;
- height: 1rem;
- }
-
- #expandedRuleDescription.collapse.show::after {
- content: none;
- }
-
- #expandedRuleDescription.collapse:not(.show) {
margin-top: 2rem;
- overflow: hidden;
- display: block;
- max-height: 3rem;
}
-
- #expandedRuleCollapseButton {
- margin-top: 0.5rem;
- margin-bottom: 1.5rem;
- border: 0;
- background: none;
- color: #0047fa;
- padding: 0;
- }
-
- #expandedRuleCollapseButton.collapsed::after {
- content: 'Read More';
- }
-
- #expandedRuleCollapseButton:not(.collapsed)::after {
- content: 'Show Less';
- }
-
#expandedRuleHelpUrl {
display: block;
margin-bottom: 1rem;
width: fit-content;
}
- #expandedRule h4 {
+ #expandedRule #conformance-header {
font-size: 1rem;
font-weight: bold;
line-height: 1.75rem;
@@ -547,6 +531,11 @@
position: static;
margin-bottom: 2rem;
}
+ #expandedRule #issue-page-count {
+ font-size: 1.125rem;
+ line-height: 2rem;
+ font-weight: bold;
+ }
#expandedRule .offcanvas-body {
background-color: #f6f8f9;
border-top: 1px solid #b5c5ca;
@@ -598,6 +587,10 @@
border-top-right-radius: 0.25rem;
border-bottom-right-radius: 0.25rem;
}
+ #expandedRuleCategorySelectors .category-name {
+ font-size: 1rem;
+ line-height: 1.75rem;
+ }
#expandedRuleCategorySelectors .category-name::before {
height: 1.125rem;
width: 1.125rem;
@@ -695,6 +688,10 @@
width: 80%;
flex-shrink: 0;
}
+ .page-item-card-section-content ul {
+ list-style: inside;
+ list-style-position: outside;
+ }
#expandedRuleCategoryContent .accordion-body pre {
background-color: #f6f8f9;
border: 1px solid #b5c5ca;