{"id":295,"date":"2019-06-04T15:48:11","date_gmt":"2019-06-04T19:48:11","guid":{"rendered":"https:\/\/pressbooks.library.ryerson.ca\/iwacc\/?post_type=chapter&#038;p=295"},"modified":"2019-11-19T10:44:52","modified_gmt":"2019-11-19T15:44:52","slug":"4-1-compatible-level-a-and-aa","status":"publish","type":"chapter","link":"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/chapter\/4-1-compatible-level-a-and-aa\/","title":{"raw":"4.1 Compatible (Level A and AA)","rendered":"4.1 Compatible (Level A and AA)"},"content":{"raw":"<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #eb974e\">\r\n<h2><strong>Guideline 4.1<\/strong> Compatible<\/h2>\r\nMaximize compatibility with current and future user agents, including assistive technologies.\r\n\r\n<\/div>\r\n<strong>Why is compatibility important?<\/strong>\r\n\r\nThe goal of <strong>Guideline 4.1<\/strong> is to ensure that web pages display correctly and work as the author intends in the following cases:\r\n<ul>\r\n \t<li>All current and future browsers, web-enabled devices, and assistive technologies<\/li>\r\n \t<li>All current and future assistive technologies<\/li>\r\n<\/ul>\r\nNot all users have up-to-date technologies. Compatible web pages also work reasonably well in older and obsolete browsers, web-enabled devices, and assistive technologies. Obviously, not all features available on modern websites are compatible with older technologies.\r\n\r\n<strong>Guideline 4.1<\/strong> requires web authors to confirm the following:\r\n<ol>\r\n \t<li>Ensure that code does not \u201cbreak\u201d or otherwise impede assistive technologies<\/li>\r\n \t<li>Expose information in standard ways so that assistive technologies can recognize and interact with content<\/li>\r\n<\/ol>\r\nWeb technologies change quickly, and assistive technology developers are constantly playing catch-up. When web authors code according to specification, they maximize the chances that assistive technologies will work seamlessly with present and future technologies.\r\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #ffcb05\">\r\n<h3><strong><a id=\"4.1.1\"><\/a>Success Criterion 4.1.1<\/strong> Parsing<\/h3>\r\nLevel A\r\n\r\nIn content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.\r\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #3c3\">\r\n\r\n<strong>Note: <\/strong>Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute-value quotation mark are not complete.\r\n\r\n<\/div>\r\n<\/div>\r\n<h4>Parsing Explained<\/h4>\r\nEnsure web pages conform to all markup language specifications.\r\n\r\nConforming to <strong>SC 4.1.1<\/strong> ensures that browsers, web-enabled devices, and assistive technologies interpret, parse, and display content accurately. Improper markup may cause content to display differently in different browsers or devices, display incorrectly, not display at all, or be inaccessible to assistive technologies.\r\n\r\nAn easy way to test <strong>SC 4.1.1<\/strong> is to use a validation tool, such as the <a href=\"http:\/\/validator.w3.org\/\">W3C Markup Validation Service<\/a>. A good validator will detect incomplete start and end tags, missing quotation marks, problems with attributes, duplicate IDs, and more.\r\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #3c3\">\r\n\r\n<strong>Toolkit: <\/strong>Add the <a href=\"http:\/\/validator.w3.org\/\">W3C Markup Validation Service<\/a> to your toolkit and use it to test how well websites comply with the HTML5 standard.\r\n\r\n<\/div>\r\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #0000ff\">\r\n\r\n<strong>Suggested Reading:<\/strong>\r\n<ul>\r\n \t<li><a href=\"https:\/\/www.w3.org\/WAI\/WCAG21\/Understanding\/parsing.html\">Understanding Parsing<\/a><\/li>\r\n \t<li><a href=\"https:\/\/www.w3.org\/WAI\/WCAG21\/quickref\/#parsing\">How to Meet Parsing<\/a><\/li>\r\n<\/ul>\r\n<\/div>\r\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #ffcb05\">\r\n<h3><strong><a id=\"4.1.2\"><\/a>Success Criterion 4.1.2<\/strong> Name, Role, Value<\/h3>\r\nLevel A\r\n\r\nFor all <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-user-interface-components\">user interface components<\/a> (including, but not limited to, form elements, links, and components generated by scripts), the <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-name\">name<\/a> and <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-role\">role<\/a> can be <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-programmatically-determinable\">programmatically determined<\/a>; states, properties, and values that can be set by the user can be <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-programmatically-set\">programmatically set<\/a>; and notification of changes to these items is available to <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-user-agents\">user agents<\/a>, including <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-assistive-technologies\">assistive technologies<\/a>.\r\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #3c3\">\r\n\r\n<strong>Note: <\/strong>This success criterion is primarily for web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.\r\n\r\n<\/div>\r\n<\/div>\r\n<h4>Name, Role, Value Explained<\/h4>\r\nEnsure that assistive technologies can gather information about, activate, set, and update user-interface controls.\r\n\r\n<strong>SC 4.1.2<\/strong> does not apply when web authors use standard controls according to specification. When web authors create custom controls or code (or script) interface elements, measures must be taken to ensure that the controls and assistive technologies are able to communicate.\r\n\r\nUse a programmatically determinable name for all user interface components. Providing the role, state, and value of all user interface components enables compatibility with assistive technologies.\r\n\r\n<a href=\"https:\/\/www.w3.org\/TR\/wai-aria-1.1\/\">WAI-ARIA<\/a>, which is covered on the next page, and in another resource in this series, is typically used to define roles, states, and properties (and their values).\r\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #3c3\">\r\n\r\n<strong>Toolkit: <\/strong>Add the <a href=\"https:\/\/developers.google.com\/web\/tools\/lighthouse\/\">Lighthouse<\/a> extension to Chrome and use it to test that the WAI-ARIA added to custom interface components is being used correctly.\r\n\r\n<\/div>\r\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #3c3\">\r\n\r\n<strong>Toolkit: <\/strong>Also add the <a href=\"https:\/\/chrome.google.com\/webstore\/detail\/axe\/lhdoppojpmngadmnindnejefpokejbdd\">aXe Chrome extension<\/a> to Chrome, which can also be used to validate WAI-ARIA.\r\n\r\n<\/div>\r\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #0000ff\">\r\n\r\nSuggested Reading:\r\n<ul>\r\n \t<li><a href=\"https:\/\/www.w3.org\/WAI\/WCAG21\/Understanding\/name-role-value.html\">Understanding Name, Role, Value<\/a><\/li>\r\n \t<li><a href=\"https:\/\/www.w3.org\/WAI\/WCAG21\/quickref\/#name-role-value\">How to Meet Name, Role, Value <\/a><\/li>\r\n<\/ul>\r\n<\/div>\r\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #ffcb05\">\r\n<h3><strong><a id=\"4.1.3\"><\/a>Success Criterion 4.1.3<\/strong> Status Messages<\/h3>\r\n<span style=\"background-color: #00ff00;border: thin solid green;padding: 0.2em\"><strong>WCAG 2.1<\/strong><\/span>\r\n\r\nLevel AA\r\n\r\nIn content implemented using markup languages, <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-status-messages\">status messages<\/a> can be <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-programmatically-determinable\">programmatically determined<\/a> through <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-role\">role<\/a> or properties such that they can be presented to the user by <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-assistive-technologies\">assistive technologies<\/a> without receiving focus.\r\n\r\n<\/div>\r\n<h4>Status Messages Explained<\/h4>\r\n<strong>SC 4.1.3<\/strong> helps ensure that assistive technology users, particularly people who are blind, receive feedback after completing an action. For typical website visitors, feedback such as confirmation, error, or warning messages are presented to them on the screen, often updating the content of the page without reloading it. They are usually visually recognizable. For screen reader users, this dynamically added content will typically go unnoticed if it has not been created in a way that screen readers are able to identify.\r\n\r\nFortunately, with the introduction of WAI-ARIA, providing feedback to screen readers is relatively simple. It\u2019s as uncomplicated as adding a type of live region role that announces itself to a screen reader when the content of the associated element changes. There are a number of live region roles that can be added to feedback messages to ensure they are announced, such as:\r\n<ul>\r\n \t<li><code>role=\"alert\"<\/code><\/li>\r\n \t<li><code>role=\"status\"<\/code><\/li>\r\n \t<li><code>role=\"log\"<\/code><\/li>\r\n<\/ul>\r\nAfter submitting a registration form, a feedback message may appear on the page after it has been submitted. Having the content of the feedback automatically read when the page loads ensures the screen reader user gets the message and is not left wondering whether the action just completed was successful or not. In this case, a status message can be presented to the user, as in the following feedback message:\r\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #0be\">\r\n\r\n<strong>Technical:<\/strong>\r\n<div role=\"status\">\r\n<pre>&lt;div role=\"status\"&gt;\r\nThank you for submitting your registration. \r\nYou will be contacted shortly.\r\n&lt;\/div&gt;<\/pre>\r\n<\/div>\r\n<\/div>\r\nAn error message might be injected into a form next to a required email field, after leaving the email field empty. The page does not reload, but instead a highlighted message is inserted next to the email field using JavaScript. The message reads automatically when it appears.\r\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #0be\">\r\n\r\n<strong>Technical:<\/strong>\r\n<pre>&lt;span role=\"alert\"&gt;\r\nEmail address is required\r\n&lt;\/span&gt;<\/pre>\r\n<\/div>\r\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #0000ff\">\r\n\r\n<strong>Suggested Reading:<\/strong>\r\n<ul>\r\n \t<li><a href=\"https:\/\/www.w3.org\/WAI\/WCAG21\/Understanding\/status-messages.html\">Understanding Status Messages<\/a><\/li>\r\n \t<li><a href=\"https:\/\/www.w3.org\/WAI\/WCAG21\/quickref\/#status-messages\">How to Meet Status Messages <\/a><\/li>\r\n<\/ul>\r\n<\/div>","rendered":"<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_80 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Contents<\/p>\n<label for=\"ez-toc-cssicon-toggle-item-69e3eb7940341\" class=\"ez-toc-cssicon-toggle-label\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/label><input type=\"checkbox\"  id=\"ez-toc-cssicon-toggle-item-69e3eb7940341\"  aria-label=\"Toggle\" \/><nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/chapter\/4-1-compatible-level-a-and-aa\/#Guideline_41_Compatible\" >Guideline 4.1 Compatible<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/chapter\/4-1-compatible-level-a-and-aa\/#Success_Criterion_411_Parsing\" >Success Criterion 4.1.1 Parsing<\/a><ul class='ez-toc-list-level-4' ><li class='ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/chapter\/4-1-compatible-level-a-and-aa\/#Parsing_Explained\" >Parsing Explained<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/chapter\/4-1-compatible-level-a-and-aa\/#Success_Criterion_412_Name_Role_Value\" >Success Criterion 4.1.2 Name, Role, Value<\/a><ul class='ez-toc-list-level-4' ><li class='ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/chapter\/4-1-compatible-level-a-and-aa\/#Name_Role_Value_Explained\" >Name, Role, Value Explained<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/chapter\/4-1-compatible-level-a-and-aa\/#Success_Criterion_413_Status_Messages\" >Success Criterion 4.1.3 Status Messages<\/a><ul class='ez-toc-list-level-4' ><li class='ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/chapter\/4-1-compatible-level-a-and-aa\/#Status_Messages_Explained\" >Status Messages Explained<\/a><\/li><\/ul><\/li><\/ul><\/li><\/ul><\/nav><\/div>\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #eb974e\">\n<h2><span class=\"ez-toc-section\" id=\"Guideline_41_Compatible\"><\/span><strong>Guideline 4.1<\/strong> Compatible<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Maximize compatibility with current and future user agents, including assistive technologies.<\/p>\n<\/div>\n<p><strong>Why is compatibility important?<\/strong><\/p>\n<p>The goal of <strong>Guideline 4.1<\/strong> is to ensure that web pages display correctly and work as the author intends in the following cases:<\/p>\n<ul>\n<li>All current and future browsers, web-enabled devices, and assistive technologies<\/li>\n<li>All current and future assistive technologies<\/li>\n<\/ul>\n<p>Not all users have up-to-date technologies. Compatible web pages also work reasonably well in older and obsolete browsers, web-enabled devices, and assistive technologies. Obviously, not all features available on modern websites are compatible with older technologies.<\/p>\n<p><strong>Guideline 4.1<\/strong> requires web authors to confirm the following:<\/p>\n<ol>\n<li>Ensure that code does not \u201cbreak\u201d or otherwise impede assistive technologies<\/li>\n<li>Expose information in standard ways so that assistive technologies can recognize and interact with content<\/li>\n<\/ol>\n<p>Web technologies change quickly, and assistive technology developers are constantly playing catch-up. When web authors code according to specification, they maximize the chances that assistive technologies will work seamlessly with present and future technologies.<\/p>\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #ffcb05\">\n<h3><span class=\"ez-toc-section\" id=\"Success_Criterion_411_Parsing\"><\/span><strong><a id=\"4.1.1\"><\/a>Success Criterion 4.1.1<\/strong> Parsing<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Level A<\/p>\n<p>In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.<\/p>\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #3c3\">\n<p><strong>Note: <\/strong>Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute-value quotation mark are not complete.<\/p>\n<\/div>\n<\/div>\n<h4><span class=\"ez-toc-section\" id=\"Parsing_Explained\"><\/span>Parsing Explained<span class=\"ez-toc-section-end\"><\/span><\/h4>\n<p>Ensure web pages conform to all markup language specifications.<\/p>\n<p>Conforming to <strong>SC 4.1.1<\/strong> ensures that browsers, web-enabled devices, and assistive technologies interpret, parse, and display content accurately. Improper markup may cause content to display differently in different browsers or devices, display incorrectly, not display at all, or be inaccessible to assistive technologies.<\/p>\n<p>An easy way to test <strong>SC 4.1.1<\/strong> is to use a validation tool, such as the <a href=\"http:\/\/validator.w3.org\/\">W3C Markup Validation Service<\/a>. A good validator will detect incomplete start and end tags, missing quotation marks, problems with attributes, duplicate IDs, and more.<\/p>\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #3c3\">\n<p><strong>Toolkit: <\/strong>Add the <a href=\"http:\/\/validator.w3.org\/\">W3C Markup Validation Service<\/a> to your toolkit and use it to test how well websites comply with the HTML5 standard.<\/p>\n<\/div>\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #0000ff\">\n<p><strong>Suggested Reading:<\/strong><\/p>\n<ul>\n<li><a href=\"https:\/\/www.w3.org\/WAI\/WCAG21\/Understanding\/parsing.html\">Understanding Parsing<\/a><\/li>\n<li><a href=\"https:\/\/www.w3.org\/WAI\/WCAG21\/quickref\/#parsing\">How to Meet Parsing<\/a><\/li>\n<\/ul>\n<\/div>\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #ffcb05\">\n<h3><span class=\"ez-toc-section\" id=\"Success_Criterion_412_Name_Role_Value\"><\/span><strong><a id=\"4.1.2\"><\/a>Success Criterion 4.1.2<\/strong> Name, Role, Value<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Level A<\/p>\n<p>For all <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-user-interface-components\">user interface components<\/a> (including, but not limited to, form elements, links, and components generated by scripts), the <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-name\">name<\/a> and <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-role\">role<\/a> can be <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-programmatically-determinable\">programmatically determined<\/a>; states, properties, and values that can be set by the user can be <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-programmatically-set\">programmatically set<\/a>; and notification of changes to these items is available to <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-user-agents\">user agents<\/a>, including <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-assistive-technologies\">assistive technologies<\/a>.<\/p>\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #3c3\">\n<p><strong>Note: <\/strong>This success criterion is primarily for web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.<\/p>\n<\/div>\n<\/div>\n<h4><span class=\"ez-toc-section\" id=\"Name_Role_Value_Explained\"><\/span>Name, Role, Value Explained<span class=\"ez-toc-section-end\"><\/span><\/h4>\n<p>Ensure that assistive technologies can gather information about, activate, set, and update user-interface controls.<\/p>\n<p><strong>SC 4.1.2<\/strong> does not apply when web authors use standard controls according to specification. When web authors create custom controls or code (or script) interface elements, measures must be taken to ensure that the controls and assistive technologies are able to communicate.<\/p>\n<p>Use a programmatically determinable name for all user interface components. Providing the role, state, and value of all user interface components enables compatibility with assistive technologies.<\/p>\n<p><a href=\"https:\/\/www.w3.org\/TR\/wai-aria-1.1\/\">WAI-ARIA<\/a>, which is covered on the next page, and in another resource in this series, is typically used to define roles, states, and properties (and their values).<\/p>\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #3c3\">\n<p><strong>Toolkit: <\/strong>Add the <a href=\"https:\/\/developers.google.com\/web\/tools\/lighthouse\/\">Lighthouse<\/a> extension to Chrome and use it to test that the WAI-ARIA added to custom interface components is being used correctly.<\/p>\n<\/div>\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #3c3\">\n<p><strong>Toolkit: <\/strong>Also add the <a href=\"https:\/\/chrome.google.com\/webstore\/detail\/axe\/lhdoppojpmngadmnindnejefpokejbdd\">aXe Chrome extension<\/a> to Chrome, which can also be used to validate WAI-ARIA.<\/p>\n<\/div>\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #0000ff\">\n<p>Suggested Reading:<\/p>\n<ul>\n<li><a href=\"https:\/\/www.w3.org\/WAI\/WCAG21\/Understanding\/name-role-value.html\">Understanding Name, Role, Value<\/a><\/li>\n<li><a href=\"https:\/\/www.w3.org\/WAI\/WCAG21\/quickref\/#name-role-value\">How to Meet Name, Role, Value <\/a><\/li>\n<\/ul>\n<\/div>\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #ffcb05\">\n<h3><span class=\"ez-toc-section\" id=\"Success_Criterion_413_Status_Messages\"><\/span><strong><a id=\"4.1.3\"><\/a>Success Criterion 4.1.3<\/strong> Status Messages<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><span style=\"background-color: #00ff00;border: thin solid green;padding: 0.2em\"><strong>WCAG 2.1<\/strong><\/span><\/p>\n<p>Level AA<\/p>\n<p>In content implemented using markup languages, <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-status-messages\">status messages<\/a> can be <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-programmatically-determinable\">programmatically determined<\/a> through <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-role\">role<\/a> or properties such that they can be presented to the user by <a href=\"https:\/\/www.w3.org\/TR\/WCAG21\/#dfn-assistive-technologies\">assistive technologies<\/a> without receiving focus.<\/p>\n<\/div>\n<h4><span class=\"ez-toc-section\" id=\"Status_Messages_Explained\"><\/span>Status Messages Explained<span class=\"ez-toc-section-end\"><\/span><\/h4>\n<p><strong>SC 4.1.3<\/strong> helps ensure that assistive technology users, particularly people who are blind, receive feedback after completing an action. For typical website visitors, feedback such as confirmation, error, or warning messages are presented to them on the screen, often updating the content of the page without reloading it. They are usually visually recognizable. For screen reader users, this dynamically added content will typically go unnoticed if it has not been created in a way that screen readers are able to identify.<\/p>\n<p>Fortunately, with the introduction of WAI-ARIA, providing feedback to screen readers is relatively simple. It\u2019s as uncomplicated as adding a type of live region role that announces itself to a screen reader when the content of the associated element changes. There are a number of live region roles that can be added to feedback messages to ensure they are announced, such as:<\/p>\n<ul>\n<li><code>role=\"alert\"<\/code><\/li>\n<li><code>role=\"status\"<\/code><\/li>\n<li><code>role=\"log\"<\/code><\/li>\n<\/ul>\n<p>After submitting a registration form, a feedback message may appear on the page after it has been submitted. Having the content of the feedback automatically read when the page loads ensures the screen reader user gets the message and is not left wondering whether the action just completed was successful or not. In this case, a status message can be presented to the user, as in the following feedback message:<\/p>\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #0be\">\n<p><strong>Technical:<\/strong><\/p>\n<div role=\"status\">\n<pre>&lt;div role=\"status\"&gt;\r\nThank you for submitting your registration. \r\nYou will be contacted shortly.\r\n&lt;\/div&gt;<\/pre>\n<\/div>\n<\/div>\n<p>An error message might be injected into a form next to a required email field, after leaving the email field empty. The page does not reload, but instead a highlighted message is inserted next to the email field using JavaScript. The message reads automatically when it appears.<\/p>\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #0be\">\n<p><strong>Technical:<\/strong><\/p>\n<pre>&lt;span role=\"alert\"&gt;\r\nEmail address is required\r\n&lt;\/span&gt;<\/pre>\n<\/div>\n<div style=\"margin: 1em 0;padding: 1em;border: 1px solid #ddd;border-left: 10px solid #0000ff\">\n<p><strong>Suggested Reading:<\/strong><\/p>\n<ul>\n<li><a href=\"https:\/\/www.w3.org\/WAI\/WCAG21\/Understanding\/status-messages.html\">Understanding Status Messages<\/a><\/li>\n<li><a href=\"https:\/\/www.w3.org\/WAI\/WCAG21\/quickref\/#status-messages\">How to Meet Status Messages <\/a><\/li>\n<\/ul>\n<\/div>\n","protected":false},"author":100,"menu_order":2,"template":"","meta":{"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":[],"pb_section_license":""},"chapter-type":[],"contributor":[],"license":[],"class_list":["post-295","chapter","type-chapter","status-publish","hentry"],"part":36,"_links":{"self":[{"href":"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/wp-json\/pressbooks\/v2\/chapters\/295","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/wp-json\/wp\/v2\/users\/100"}],"version-history":[{"count":11,"href":"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/wp-json\/pressbooks\/v2\/chapters\/295\/revisions"}],"predecessor-version":[{"id":1302,"href":"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/wp-json\/pressbooks\/v2\/chapters\/295\/revisions\/1302"}],"part":[{"href":"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/wp-json\/pressbooks\/v2\/parts\/36"}],"metadata":[{"href":"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/wp-json\/pressbooks\/v2\/chapters\/295\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/wp-json\/wp\/v2\/media?parent=295"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/wp-json\/pressbooks\/v2\/chapter-type?post=295"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/wp-json\/wp\/v2\/contributor?post=295"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/pressbooks.library.torontomu.ca\/iwacc\/wp-json\/wp\/v2\/license?post=295"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}