IAAP WAS EXAM 2024 QUESTIONS WITH 100% ACTUAL ANSWERS!!

First thing screen readers hear: - ANS- Page title (also this is good for SEO) Page title rules: - ANS- 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. - ANS- 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. - ANS- Using 2 letter language code or LCID string. Inline language changes MUST be identified with a valid lang attribute. - ANS- 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: pWhile in Spain, my friend tried to speak Spanish, but she wasn't very good. Everyone kept saying "span lang="es"No comprendo nada de lo que dices./span"/p Landmarks SHOULD be used to designate pre-defined parts of the layout (header, nav, main, footer, etc.). - ANS- Use either HTML 5 landmarks or their ARIA equivalents to mark sections of the layout in the design, so that screen reader users can easily find their way around the layout. Landmarks are used to designate sections of the overall page design and layout. Headings are used to designate sections within the content. All text SHOULD be contained within a landmark region. - ANS- Labels for headers, mains, sections, articles, asides, footers, etc. Using just div isn't enough. Multiple instances of the same type of landmark SHOULD be distinguishable by different discernible labels (aria-label or aria-labelledby). - ANS- Example: nav aria-label="Corporate and legal info" A page SHOULD NOT contain more than one instance of each of the following landmarks: banner, main, and contentinfo. - ANS- The ARIA specification states that the landmarks role="banner", role="main", and role="contentinfo" are meant to be used only once per page. Other ARIA landmarks can be used multiple times. Interestingly, the HMTL 5 specification allows multiple instances of the equivalent landmarks: header, main, and footer. The official restriction is only on ARIA landmarks. Even so, it is appropriate in most web designs to have only one each of these landmarks, whether they are specified using ARIA or HTML 5. The total number of landmarks SHOULD be minimized to the extent appropriate for the content. - ANS- 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. - ANS- Text that acts as a heading visually or structurally SHOULD be designated as a true heading in the markup. - ANS- 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 h1, h2, h3, h4, h5, or h6. Text that does not act as a heading visually or structurally SHOULD NOT be marked as a heading. - ANS- If you want to create big, bold text for non-heading text, use styles to achieve that effect. If you use heading markup (h1, h2, 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. - ANS- 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. - ANS- 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. - ANS- 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 h1. - ANS- Usually the best practice is to start the main content of a web page with a level 1 heading (h1), with no other headings before this high-level heading. Most web pages SHOULD have only one h1. - ANS- 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. - ANS- They need an a element and a valid href value. OR Aria role=link and tabindex=0. Links and buttons SHOULD be designated semantically according to their functions. - ANS- 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. - ANS- A link must have a text-based name associated with it so that screen readers can read something to users. If a link has no name associated with it, most screen readers will read the link destination in the href as a way to give users some sort of clue to the purpose of the link. aria-labelledby aria-label Text contained between the opening a and closing /a elements (including alt text on images) title attribute (note that this is considered a last resort method for screen readers to find something; it should not be considered a primary technique for giving names to links) The purpose of each link SHOULD be able to be determined from the link text alone. - ANS- Screen reader users often listen to links out of context, either by navigating through the links, or by using a keyboard command to list all of the links on the page. The best technique is to make sure all links make sense out of context. The link text SHOULD NOT repeat the role ("link"). - ANS- Screen readers will say "link" and then read the link text, so there is no need to include the word "link" in the link text. Features such as labels, names, and text alternatives for content that have the same functionality across multiple web pages MUST be consistently identified. - ANS- Can't have a link be labelled under two different labels. A link that opens in a new window or tab SHOULD indicate that it opens in a new window or tab. - ANS- It can be helpful to users to know when a link will open a new window. Including a text indication (e.g. "opens in a new window") 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 a file or destination in an alternative or non-web format SHOULD indicate the file or destination type. - ANS- 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. - ANS- 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. - ANS- 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. - ANS- 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. - ANS- 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 nav element or role="navigation". - ANS- 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. - ANS- A navigation list SHOULD include a method of informing blind users which page within the navigation list is the currently active/visible page. - ANS- 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 Navigation patterns that are repeated on web pages MUST be presented in the same relative order each time they appear and MUST NOT change order when navigating through the site. - ANS- Users will have a hard time finding their way around a web site if the number and order of links in the main menu is not consistent. A keyboard-functional "skip" link SHOULD be provided to allow keyboard users to navigate directly to the main content. - ANS- The top section of a web page can be quite long. Providing a way to skip past all of the features at the top of a web page helps save keystrokes for keyboard users. The "skip link" SHOULD be the first focusable element on the page. - ANS- A "skip navigation link" should be placed at the very beginning of the document, right after the opening body tag, to allow users to go past repetitive navigation, such as global navigation menus. It should point to the id at or just before the beginning of the main content on the page. Often the appropriate destination is the h1 at the beginning of the main content. A skip link MUST be either visible at all times or visible on keyboard focus. - ANS- Option 1: Make the link visible all the time The most accessible — though also probably the least popular — way to include a "skip navigation" link in a design is to make it visible all of the time. All users, whether sighted or blind, will be able to take advantage of "skip navigation" links like this. Option 2: Make the link visible on keyboard focus Designers tend not to like the look of visible "skip navigation" links, so they tend to hide them from sighted users. That can be acceptable, as long as the link becomes visible when it receives keyboard focus. The link can be hidden by default, using the CSS clip technique, then made visible by removing the CSS clip when the link receives focus. A table of contents for the page MAY be included at the top of the content or in the header. - ANS- 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. - ANS- 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 - ANS- 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. - ANS- 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. - ANS- 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. - ANS- 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. - ANS- 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. - ANS- 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 h1 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 table. - ANS- 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). Don't create fake tables - ANS- Fake tables don't have the semantic meaning and structure for blind users to utilize screen readers to navigate them. They are ineffective to navigate. Data tables SHOULD have a programmatically-associated caption or name. - ANS- Screen readers read the caption or name of the table when users navigate to the table, giving users a sense of what the table is about. The caption element is the most straightforward way to give a name to a table. It is also possible to use aria-label or aria-labelledby. The name/caption of a data table SHOULD describe the identity or purpose of the table accurately, meaningfully, and succinctly. - ANS- The purpose of the caption or name is to allow users to identify the table and/or understand the purpose of the table, so the caption or name should be meaningful. Just saying "Table 1," for example, would not be helpful. An alternative would be "Table 1: First Quarter Earnings." The name/caption of each data table SHOULD be unique within the context of other tables on the same page. - ANS- If there are two or more tables on the same page with the same caption or name, screen reader users will not be able to distinguish the tables when they pull up the list of all of the tables on the page. Table headers MUST be designated with th. - ANS- The only way that screen readers can know if a table cell is a header is by marking it with th. Otherwise screen readers may assume the table is just for visual formatting and will not read the header information as they should. Data table header text MUST accurately describe the category of the corresponding data cells. - ANS- If the text in the header cell is vague (for example, naming it "Column 2"), or if it contains extraneous information (like links, buttons or extra descriptions that aren't the name of the column), it can 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. - ANS- 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. - ANS- 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 th and scope MUST be designated with headers plus id - ANS- 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. - ANS- 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. - ANS- 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. - ANS- 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. - ANS- 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 caption element The summary attribute The th element The scope attribute The headers attribute Lists MUST be constructed using the appropriate semantic markup. - ANS- There are three main types of lists in HTML: Unordered lists (ul) render as bulleted lists of list items (li). Unordered lists should be used when a set of items can be placed in any order. Ordered lists (ol) render as numbered lists of list items (li). Ordered lists should be used when the list items need to be placed in a specific order. Definition lists (or Description lists in HTML5) (dl) render as paired terms (dt) and definitions (dd). Definition/description lists are used to pair a term with its definition or a name with a value. Screen readers notify users when they come to a list and tell them how many items are in a list. This helps listeners know what they are listening to, and what to expect as they listen to it. If you don't mark up a list as a real list—for example, if you use a table to create a fake list, or you use the br element to create a fake list—screen readers cannot inform the listener that they are listening to a list, and cannot let them know how many items are in the list. Iframes that convey content to users MUST have a non-empty title attribute. The iframe title MUST be accurate and descriptive. - ANS- The source page of an iframe MUST have a valid, meaningful title. - ANS- Only if the enclosed document does not have a title element will JAWS read the title attribute of the iframe. This behavior of giving priority to the enclosed document's title is a bit of a departure from the guidelines, but since all web pages are supposed to have meaningful title tags anyway, it shouldn't matter too much that JAWS behaves differently than the other screen readers in this regard. Screen readers allow cross-frame navigation of semantic elements. - ANS- Screen readers treat an iframe almost as if it is part of the same document that contains it. Users can access all of the content within an iframe using the same keystrokes that they would use to access the content if it were all in the same document. The heading hierarchy of an iframe SHOULD be designed to fit within the heading hierarchy of the parent document, if possible. - ANS- 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 h1 at the top of the content (this is a recommended best practice), the iframe ought to take this into account, and not start with another h1. Hidden frames or frames that do not convey content to users SHOULD be hidden from assistive technologies using aria-hidden="true". - ANS- 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. - ANS- 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: em for emphasis (italics) and strong for strong emphasis (bold). Critical emphasis in the text SHOULD be conveyed in a text-based format. - ANS- All major screen readers ignore em and strong 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 blockquote element SHOULD be used to designate long (block level) quotations. - ANS- 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 blockquote element SHOULD NOT be used for visual styling alone. - ANS- It may be tempting to use blockquote 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 q element (for inline quotations) SHOULD NOT be used as the only way to designate quotations. - ANS- Even though the q 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 code element and styled to look different from non-code text. - ANS- 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 code element is a monospaced font, often Courier or Courier New. Blocks of code SHOULD be formatted with the pre element. - ANS- Using the pre 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 pre element is just for visual formatting, so it is not semantically meaningful Strikethrough text SHOULD be marked with the del element. - ANS- The semantically-correct element to use to mark deleted text is the del element. Visually, the default style for inserted text is a strikethrough line across the middle of the text. Screen readers do not support the del 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. - ANS- Text designated for insertion SHOULD be marked with the ins element. - ANS- The semantically-correct element to use to mark inserted text (usually in legal documents) is the ins element. Visually, the default style for inserted text is an underline beneath the text. Screen readers do not support the ins element. They read the text, but do not notify users that the text has been inserted. Critical text designated for insertion MUST be supplemented with a text-based method to convey the meaning of the insertion. - ANS- Highlighted text SHOULD be marked with the mark element. - ANS- Sighted users will benefit from seeing important passages highlighted, if it is appropriate for the context of the text. The semantically-correct element to use is the mark element. The default styling in browsers is to highlight the text with a yellow background color. The visual styling can be customized via css. Even though the mark element is semantically-correct, current screen readers do not notify users that a mark element is present, so there is no benefit to screen reader users (even though sighted users still benefit, because of the visual background color highlighting). Critical highlighted text SHOULD be supplemented with a text-based method to convey the meaning of the highlighting. - ANS- Most of the time, highlighting can be considered a visual enhancement that screen reader users do not need to be aware of. That said, if the meaning of the text is lost without the visual highlighting, you will need to supplement the highlighting with some text that screen readers can access, because screen readers do not notify users about CSS highlighting or the mark element. The mark element ought to be sufficient, since it is a semantic element, but you will have to employ workarounds if readers need to know about the highlighting IDs MUST be unique within a web page. - ANS- 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. - ANS- 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. - ANS- Deprecated markup SHOULD NOT be used. - ANS- Most of the time, deprecated markup does not have any impact on accessibility, but the marquee and blink elements can be particularly distracting, and there is no way to pause them, and are therefore against accessibility guidelines