WEB ACCESSIBILITY SPECIALIST (WAS) CERTIFICATION - SEMANTIC STRUCTURE AND NAVIGATION SCORED A+
WAS
Evatee 10/5/24 WAS
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Accessibility Considerations for HTML Elements, Exams of Nursing
Insights into the accessibility considerations for various html elements, focusing on how screen readers and other assistive technologies interact with these elements. It covers topics such as the proper use of the lang attribute, heading markup, links and buttons, table accessibility, list structures, and the handling of elements like blockquotes, del, ins, and mark. The document emphasizes the importance of ensuring that the structure and semantics of the html code are aligned with the needs of users relying on assistive technologies, as they pay attention to the underlying structure rather than the visual presentation. By understanding these accessibility principles, web developers can create more inclusive and user-friendly digital experiences.
Typology: Exams
2023/2024
1 / 19
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Accessibility Considerations for HTML Elements and more Exams Nursing in PDF only on Docsity!
WEB ACCESSIBILITY SPECIALIST (WAS) CERTIFICATION - SEMANTIC STRUCTURE AND NAVIGATION SCORED A+ WAS Evatee 1 0/5/24 WAS
WEB ACCESSIBILITY SPECIALIST (WAS)
CERTIFICATION - SEMANTIC STRUCTURE AND
NAVIGATION SCORED A+
First thing screen readers hear: Answer - Page (also this is good for SEO) Page <title> rules: Answer - Page <title> must be present and must contain text. Must be updated when the web address changes. Must be accurate and informative. If a page is the result of a user action or scripted change of context, the text of the <title> SHOULD describe the result or change of context to the user. Should be concise. Should be unique if possible. Unique information should come first. The page <title> SHOULD match (or be very similar to) the top heading in the main content. The primary language of the page MUST be identified accurately on the <html> element. Answer - If the language is not specified, or if it the language designation is inaccurate, a screen reader will read the document in the user's default language, which may result in a very bad accent if the page language doesn't match the user's default. Or not understandable. The primary language of the page MUST be identified with a valid value on the <html> element. Answer - Using 2 letter language code or LCID string. Inline language changes MUST be identified with a valid lang attribute. Answer
- Identify any changes of language within the document. The lang attribute can be applied to block level elements (<div>, <h1>, <p>, <table>, etc.) as well as inline elements (<span>, <a>, <strong>, etc.). Example:
The total number of landmarks SHOULD be minimized to the extent appropriate for the content. Answer - One of the main purposes of landmarks is to allow blind users to quickly find and navigate to the appropriate landmark, so you should keep the total number of landmarks relatively low. If you don't, screen reader users will have to sort through too much extra information to find what they're looking for. Landmarks SHOULD be made backward compatible. Answer - Text that acts as a heading visually or structurally SHOULD be designated as a true heading in the markup. Answer - Headings are about logical structure, not visual effects. Big bold text may look like a heading to visual users, but screen readers ignore the size and font-weight of the text, so blind users cannot know a phrase is a heading unless it is marked up in the HTML code as such, using , , , , , or . Text that does not act as a heading visually or structurally SHOULD NOT be marked as a heading. Answer - If you want to create big, bold text for non- heading text, use styles to achieve that effect. If you use heading markup (, , etc.) for non-heading text, you will confuse screen reader users by creating an inaccurate structural outline of the page contents. Headings MUST be accurate and informative. Answer - Headings should be descriptive enough to give users a good sense of the content they will find within that section of the document. When screen reader users pull up the list of headings, they will hear the level of the heading, plus the text within the heading, including alt text for any images inside the heading. Heading text SHOULD be concise and relatively brief. Answer - There is no technical limit on the length of a heading, but a heading should be a short label for the section of content below the heading, to make it easy for users to browse the headings.
Headings SHOULD convey a clear and accurate structural outline of the sections of content of a web page. Answer - lways think about the structure first, because screen readers and other assistive technologies pay attention to the structure, not the look and feel. If the default size of the headings is too big for the look you have in mind, use styles to change the size, rather than jumping down to a lower heading level. The beginning of the main content SHOULD start with . Answer - Usually the best practice is to start the main content of a web page with a level 1 heading (), with no other headings before this high-level heading. Most web pages SHOULD have only one . Answer - With few exceptions, most web pages should have only one heading level 1, to make it clear where the beginning of the main content is. Links MUST be semantically designated as such. Answer - They need an element and a valid href value. OR Aria role=link and tabindex=0. Links and buttons SHOULD be designated semantically according to their functions. Answer - Links take users to different locations (either to a different page or to a different location on the same page); Buttons activate scripted functionality (e.g. make a dialog appear, expand a collapsed menu, turn font bold, etc.), usually on the same page, but a button can also submit form data. Screen readers always say "link" before links, and "button" before buttons, so screen reader users always know which is which, at least in terms of the markup. A link MUST have programmatically-discernible text, as determined by the accessible name calculation algorithm. Answer - A link must have a text-based name associated with it so that screen readers can read something to users. If
A link to a file or destination in an alternative or non-web format SHOULD indicate the file or destination type. Answer - It can be helpful to users to know when a link will open a file or lead to a destination in a non-web format, such as a Word document, PDF document, Photoshop document, etc. Including a text indication (e.g. "PDF document") or an icon with equivalent alt text are two of the most common ways to indicate this. Ensure the indication is available to both sighted users and blind screen reader users. A link to an external site MAY indicate that it leads to an external site. Answer - It can be helpful to users to know when a link will take them away from the current web site to a different web site. Including a text indication (e.g. "link leads to an external site") or an icon with equivalent alt text are two of the most common ways to indicate this. Ensure the indication is available to both sighted users and blind screen reader users. Links MUST be visually distinguishable from surrounding text. Answer - Sighted users must be able to tell the difference visually between link text that is within a paragraph or other block of text and surrounding text. If they can't tell the difference, they won't know what items are clickable, and they may miss important links. There is no need to change the default styling to meet accessibility best practices. All focusable elements MUST have a visual focus indicator when in focus. Answer - Browsers typically indicate which element is in focus by outlining it with either a dotted line (as in Edge, Internet Explorer, and Firefox) or a solid colored line (as in Chrome and Safari). Focusable elements SHOULD have enhanced visual focus indicator styles. Answer - Although not typically required for minimum compliance with guidelines, users with low vision can benefit greatly from enhanced visual focus indicators on links, buttons, form elements, and other focusable items.
Enhancements can include a different background color, different font color, outline, or border. A navigation list SHOULD be designated with the element or role="navigation". Answer - The main navigation list(s) of a web design — such as the main navigation menu — should be marked as navigation landmarks so that screen reader users can easily find them when they pull up the list of landmarks. It is not necessary, or even desirable, to mark every set of links as a navigation landmark. The landmark should be reserved for the most important navigation regions on the page, so that the list of landmarks does not get too cluttered. A navigation list SHOULD include a visible method of informing users which page within the navigation list is the currently active/visible page. Answer - A navigation list SHOULD include a method of informing blind users which page within the navigation list is the currently active/visible page. Answer - Unfortunately, there is no official HTML or ARIA attribute that can be used to designate the current page within a navigation list (though there is talk of creating one for the next version of ARIA), so we have to resort to techniques such as: Visually hidden text aria-label aria-labelledby aria-describedby aria-current
A table of contents for the page MAY be included at the top of the content or in the header. Answer - A table of contents helps with both understandability and navigation. If a table of contents for the page is included, it SHOULD reflect the heading structure of the page. Answer - In most cases, the most logical text to put in the table of contents for a page is the heading structure of the page itself. Aligning the headings and table of contents helps keep the page structure consistent and well-organized. The Document Object Model (DOM) order determines the reading order and tab Answer - When screen reader users navigate straight through the content linearly, the order that they hear the content is determined by the order in the document object model (DOM), which is essentially the source code after the browser has parsed it and run any relevant JavaScript. This seems intuitive enough, but here are some things to watch out for: CSS positioning techniques Injecting content dynamically via JavaScript or AJAX The reading order MUST be logical and intuitive. Answer - If the reading order is illogical or unintuitive, the content will not make sense, or it will be difficult to understand. Screen readers ignore all of the CSS layout in your web design. Turning off the style sheets is one way to check the reading order of static content. When the content is stripped bare of the visual styling like this, it is sort of how a screen reader "sees" it.
The navigation order of focusable elements MUST be logical and intuitive. Answer - When keyboard users tab through the focusable items (buttons, links, form elements, custom controls, etc.), the order needs to make sense, so they don't get confused. tabindex of positive values SHOULD NOT be used. Answer - It is possible to customize the tab order of focusable items using tabindex, by setting it to numerical values like 1, 2, 3, etc., but this has the potential to cause significant problems for keyboard users. A paginated view SHOULD include a visible method of informing users which view is the currently active/visible view. Answer - The page number of the current page can be made visually apparent in the list of page numbers by making the number bold, changing the background color, putting an outline around the number, and/or by removing the link. A paginated view SHOULD include a method of informing blind users which view is the currently active/visible view. Answer - There is no official accessibility requirement to let users know where they currently are in a paginated view, and in fact there is no native technique to do so for screen reader users, other than to use text to indicate "you are here" or "currently selected" or similar. Sometimes users can figure out where they are based on other cues, such as the page title or the text in the at the beginning of the main content, but it is a better user experience if the current location can also be explicitly available to the screen reader user. aria-current Tabular data SHOULD be represented in a . Answer - Screen reader users are able to navigate data tables from cell to cell, in a multi-directional way (up, down, right, left), much like navigating a spreadsheet. As they move from cell to cell, screen readers will read the associated header labels (if the table has been created with accessibility in mind).
be confusing for screen reader users. It's best to keep the header text accurate and simple. Table data cells MUST be associated with their corresponding header cells. Answer - The scope attribute makes an explicit association between the table header cell and its corresponding data cells. Table data group headers MUST be associated with their corresponding data cell groups. Answer - When you merge table header cells, you need to designate one header as corresponding to multiple rows or columns. The easiest way is to use scope="rowgroup" or scope="colgroup". Screen readers will read the multiple headers when navigating through the tables. Header/data associations that cannot be designated with and scope MUST be designated with headers plus id Answer - Tables with a complex structure — in which data cells are merged or there are more than two levels of headers for any given dimension — require a different technique than simply marking the header cells with a scope of col, row, colgroup, or rowgroup. Each data cell must be explicitly associated with each corresponding header cell using headers and id. Data table headers and data associations MUST NOT be referenced across nested, merged, or separate tables. Answer - Nested data tables are data tables which exist inside other data tables. Nested data tables break the accessibility of the data presentation as a whole, making it impossible to associate the data and header cells appropriately with any of the standard methods A summary MAY be provided for data tables. Answer - A table summary is not required. Ideally the table would be simple enough and well-organized enough that the table is self-explanatory just by virtue of the headers and data structure. Even so, it can sometimes be helpful to provide a brief summary of the main points of the table, to help them understand data trends, data
format, and/or other aspects of the table that can make the table more understandable to screen reader users. Tables SHOULD NOT be used for the purpose of purely visual (non-data) layout. Answer - Using tables for visual layout and not for data tables is discouraged but is technically allowed by accessibility guidelines. There is no severe accessibility consequence for using layout tables, but tables were designed for data grids, from a semantic structure perspective, so it is better to use them only for that purpose. Layout tables MUST NOT contain data table markup. Answer - If a table is used strictly for visual layout purposes, don't include any of the header markup for data tables, because if you do, screen readers will inform users that a table is present, and users will expect the table to represent tabular data, which won't be accurate in layout tables. Specifically, layout tables should avoid: The element The attribute The element The scope attribute The headers attribute Lists MUST be constructed using the appropriate semantic markup. Answer - There are three main types of lists in HTML: Unordered lists () render as bulleted lists of list items (). Unordered lists should be used when a set of items can be placed in any order.
The heading hierarchy of an iframe SHOULD be designed to fit within the heading hierarchy of the parent document, if possible. Answer - If you have control over the content of the embedded document in the iframe, the best practice is to fit the iframe heading hierarchy into the proper place within the existing heading hierarchy of the parent page. If the parent document is structured with a single at the top of the content (this is a recommended best practice), the ought to take this into account, and not start with another . Hidden frames or frames that do not convey content to users SHOULD be hidden from assistive technologies using aria-hidden="true". Answer - Sometimes the content of an iframe is not important at all. It may contain only JavaScript, or it may be there purely for decorative purposes. If that's the case, you should hide the frame from screen readers using aria-hidden="true". Critical emphasis in the text SHOULD be conveyed through visual styling. Answer - Sometimes you want to emphasize text. Visually you can create emphasis with bold or italics. In HTML there are even semantic elements created with this exact purpose in mind: for emphasis (italics) and for strong emphasis (bold). Critical emphasis in the text SHOULD be conveyed in a text-based format. Answer - All major screen readers ignore and elements in their default configuration. If the emphasis is critical to understand the text — then you'll need to find another way to create emphasis. The element SHOULD be used to designate long (block level) quotations. Answer - Most desktop screen readers announce the blockquote element, so you can safely use it with the expectation that blind users will know that the content inside a blockquote is a quotation. The element SHOULD NOT be used for visual styling alone. Answer - It may be tempting to use purely for the visual
indentation effect, but that will convey the wrong information to screen reader users if the information inside is not a quotation. The element (for inline quotations) SHOULD NOT be used as the only way to designate quotations. Answer - Even though the element was invented as a way to designate inline quotations in a semantically-appropriate way that could be used by screen readers, most screen readers ignore this element completely, so for now it is best to simply use quotation marks (" and '). Code SHOULD be marked with the element and styled to look different from non-code text. Answer - Sighted users benefit from being able to tell, via visual styling, when code is used, so they can tell the difference between technical terms and regular prose. The default styling for the element is a monospaced font, often Courier or Courier New. Blocks of code SHOULD be formatted with the element. Answer - Using the element around blocks of code helps sighted users distinguish the code from the surrounding text. The text will be preformatted exactly as it appears in the source code, including spaces (HTML allows only one space in normal markup). The element is just for visual formatting, so it is not semantically meaningful Strikethrough text SHOULD be marked with the element. Answer - The semantically-correct element to use to mark deleted text is the element. Visually, the default style for inserted text is a strikethrough line across the middle of the text. Screen readers do not support the element. They read the text, but do not notify users that the text has been deleted. Critical strikethrough text MUST be supplemented with a text-based method to convey the meaning of the strikethrough. Answer -
IDs MUST be unique within a web page. Answer - If there are two elements on the same page with the same ID, screen readers may read the information incorrectly (like reading the wrong label with a text input), which can cause screen reader users to input the wrong information, or at a minimum to be confused. Names, when provided, of block level elements (e.g. landmarks, tables, iframes, etc.) SHOULD be unique within a web page. Answer - Screen reader users have the ability to pull up lists of landmarks (e.g. navigation, sections, forms, etc.), tables, and other block level elements. To the extent possible, each element of the same type should be given a unique name, to allow users to distinguish them. Markup SHOULD adhere to required parent-child relationships of elements and attributes. Answer - Deprecated markup SHOULD NOT be used. Answer - Most of the time, deprecated markup does not have any impact on accessibility, but the and elements can be particularly distracting, and there is no way to pause them, and are therefore against accessibility guidelines