Checkpoint 1.3.1 Info and Relationships

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

Rationale

Information displayed visually must also be made available programmatically or in the text so that the information is accessible non-visually. Sighted users take many cues from visible attributes such as proximity, organization, and visual attributes: a heading is inferred from larger and bolder text, the first row in a table is often recognized as the column header, and text placed near a form element is assumed to be the label.

Screen readers must have this information programmatically identified using platform markup or other programmatic methods so that the intended purpose of the presentation is clear to the user who cannot see it. For example, where the platform supports it, text that serves the function of a heading must be programmatically set as a heading; it is not sufficient to simply use a large bold font.

In software, programmatic determinability is best achieved through the use of accessibility services provided by platform software to enable interoperability between software and assistive technologies and accessibility features of software. Examples include IAccessible2 and MSAA.

Each visual cue must be implemented in the best form supported by the platform or technology. Common visual cues that must be supported programmatically or through markup include (but are not limited to) headings, labels, forms, tables with associated row and column headers, table and image captions, lists, emphasis (including bold and italics), hyperlinks and paragraphs.

In cases where there is no support for programmatic identification of visual cues, an alternative must be provided in the text. For example where emphasis is required, but no markup is available for emphasis, additional characters such as a double asterisk (**) may be used.

Note: The requirement is not limited only to visual cues, although they are the most common. For example, if audio cues are used to indicate required content, markup or textual identification must be additionally provided.

Refer to Understanding SC 1.3.1 for more information (external link to WCAG).

Development Techniques

Review the General techniques as well as other tabs applicable to your technology.  Prioritize the use of technology-specific techniques, and implement the General techniques as needed. You are always required to find, understand and implement accessible code techniques to meet the checkpoint. The documented techniques and supplements are not exhaustive; they illustrate acceptable ways to achieve the spirit of the checkpoint. If numbered, techniques are in order of preference, with recommended techniques listed first. Where used, IBM information that complements the WCAG techniques is indicated as supplemental.

General techniques

Instructions: Select the situation below that matches your content. Items in the described situation are sufficient techniques for applicable circumstances. Ensure you review WCAG Common Failures to avoid development mistakes.

Situation A: The technology provides semantic structure to make information and relationships conveyed through presentation programmatically determinable:

Situation B: The technology in use does NOT provide the semantic structure to make the information and relationships conveyed through presentation programmatically determinable:

General Supplements

The following examples and comments provide additional information beyond that available in the WCAG techniques.  Where items supplement existing WCAG techniques, they are numbered accordingly (e.g., G115).

G115: Using semantic elements to mark up structure

  • Explicitly indicate the role or nature of all structure of content when appropriate semantic elements are available.
  • The relationship between elements in the content should also be indicated to make structure perceivable.
  • DO NOT use changes in presentation alone to convey information.

G140: Separating information and structure from presentation to enable different presentations.

Technology, such as CSS, can be used to alter the default format of structured information. The visual presentation may be altered to render information better on a specific screen size, or for a specific user persona. An important principle is that if this presentation (e.g., CSS) is disabled, the content should still be understandable and usable based on its correct programmatic structure.

  • Where stylization is used to supplement or modify the default format of information, the content must still be understandable and usable when the modifying technology is disabled.
  • Logically separate the content’s structural and functional encoding from the presentation encoding.

G138: Using semantic markup whenever color cues are used

When color cues are provided in a UI, an alternative equivalent is required. This requirement extends to two different user groups: those who cannot see, and those who can see but not distinguish colors. Acceptable textual and visual equivalents for the latter are covered extensively under 1.4.1 Use of Color; however G138 is listed under 1.3.1 to emphasize that semantic equivalents for color can be used to support non-visual requirements.

G117: Using text to convey information that is conveyed by variations in presentation of text

Where technology cannot accessibly convey variations in text presentation, text descriptions or text conventions should be added. Although this technique is concerned with using text to reinforce variations in the presentation of text, text can also be used to reinforce other visual styling.

  • Where a technology does not have an ability to convey information and relationships programmatically, provide a text description. The text description should be near the information it is describing (when the page is linearized), such as in the parent element or in the adjacent element.
  • For detailed guidance on the use of text as the means of designating required fields, see 3.3.2 Labels or Instructions.

Web (HTML, ARIA, CSS) techniques

In addition to the General techniques, items in this section represent techniques deemed sufficient to address particular circumstances.

Situation A: The technology provides semantic structure to make information and relationships conveyed through presentation programmatically determinable:

Meet G140: Separating information and structure from presentation to enable different presentations with the following:

Meet G115: Using semantic elements to mark up structure with the following:

Structure

Tables

Labels and forms

Other

HTML supplements

ARIA11: Using ARIA landmarks to identify regions of a page

The consistent and proper use of ARIA landmarks (or an equivalent HTML5 semantic element) is one of the few required techniques in the IBM checklist. Landmarks must be used, and must be used properly. Although a few techniques for landmarks are listed in 1.3.1, considerations around their proper use are covered in detail in Checkpoint 2.4.1 Bypass Blocks.

H51: Using table markup to present tabular information

For excellent examples of tables, including discussions on the use of captions, IDs, and header cells, see the W3C tutorials for Tables Concepts.

H63: Using the scope attribute to associate header cells and data cells in data tables

For information on the use of scope, see Tables with two headers. Note that the scope attribute is not supported in HTML5 on the <td> element.

H73: Using the summary attribute of the table element to give an overview of data tables

The table summary attribute is obsolete in HTML5. The HTML5 specification suggests describing a table with the new details and summary elements. However, browser support for these elements is poor, so if your application must be HTML5 compliant, programmatically associate a summary with a table using an aria-describedby attribute to reference a description and hiding the description text, as needed.

H44: Using label elements to associate text labels with form controls

Further guidance on labels can be found in WCAG Web Accessibility Tutorials.

H65: Using the title attribute to identify form controls when the label element cannot be used

Relying on the title attribute is currently discouraged, as many user agents do not expose the attribute in an accessible manner (e.g., only a pointing device such as a mouse causes a tooltip to appear, which excludes keyboard-only users and touch-only users). In cases where a <label> element cannot be used, it is recommended to consider the use of aria-label in addition to title to provide the same information non-visibly, since it is more consistently announced by assistive technologies than the value of the title attribute.

H49: Using semantic markup to mark emphasized or special text

Use code element for code fragments

Use the <code> element to provide visual emphasis for code rendered on a web page. Text that has a fixed width (tt) provides visual emphasis, but that information is not available to assistive technology. The next example shows how to use the <code> element to emphasize a code block embedded in text.

<code>
#trial {
background-image: url(30daytrial.jpg);
background-repeat: no-repeat;
background-position: left top;
padding-top: 68px;
}
</code>
 

SCR21:Using functions of the Document Object Model (DOM) to add content to a page

When you need to add content to a page dynamically, use functions of the Document Object Model (DOM) to add the content. DOM functions createElement, createTextNode(), appendChild(), removeChild(), insertBefore() and replaceChild() are superior to document.write and object.innerHTML. Note: While using functions of the DOM is the preferred method to add content to the page, other methods are acceptable as long as the content and its semantics can be read by a screen reader.

Not using scripts to emulate HTML links

Do not use scripts to emulate an HTML link. Use <a href> or <area> to implement links. When a link is emulated by placing an onclick on a span or div, for example, the element doesn’t provide any semantic information about the link to assistive technologies and does not automatically provide the keyboard accessibility as required by Checkpoint 2.1.1 - Keyboard.

HTML link markup is preferable. However, if scripting must be used, put the WAI-ARIA role="link" on the element used as a link and implement keyboard accessibility.

Mobile Native (iOS) techniques

Instructions: In addition to the General techniques, any of these Native iOS techniques are deemed sufficient in the following situations when used as instructed.

Situation A: The technology provides semantic structure to make information and relationships conveyed through presentation programmatically determinable

 

Meet G115: Using semanic elements to mark up structure with the following:

Set the accessibility, label, hint, and trait of UI elements

Native UI elements have accessibility properties built in. You must enable and provide the content for the applicable accessibility properties. At a minimum, you should set isAccessibleElement = YES to enable the accessibility and set the label to a meaningful string. Trait is already set, and is rarely changed unless you create a custom control. Provide a hint if needed. Refer to Accessibility Programming Guide for iOS for Apple's style instructions on creating good labels and hints. Note: This technique is also included in Checkpoint 502.3.14 Event Notification.

self.button.isAccessibilityElement = YES;
self.button.label = @”Confirm”;
self.button.hint = @”Completes the transaction.”

Custom widgets implement UIAccessibility protocol. Methods on the protocol include: isAccessibilityElement to return YES; accessibilityLabel to return an appropriate label; accessibilityTrait to return the closest trait; and optionally, accessibilityHint to return a localized hint. In the following code, a custom widget that allows the user to select the angle of rotation implements the needed methods.

- (BOOL)isAccessibilityElement
{
   return YES;
}

- (NSString*)accessibilityLabel
{
   return @"Angle";
}

- (NSString*)accessibilityHint
{
   return @"Adjusts the angle of rotation";
}

- (UIAccessibilityTraits)accessibilityTraits
{
   return UIAccessibilityTraitAdjustable;

}

Use separate UI elements for simple semantic markup

iOS does not have semantic markup within native UI text-based elements. (Although UIWebView elements do; see iOS example 3.) If static text matches the purpose of any of the UIAccessibilityTraits, put the static text in separate controls and set the appropriate trait. The following traits can be used for simple identification of the purpose of separate blocks of text:

UIAccessibilityTraitLink;
UIAccessibilityTraitImage;
UIAccessibilityTraitStaticText;
UIAccessibilityTraitSummaryElement;
UIAccessibilityTraitHeader;

In iOS7, Apple introduced Text Kit, which can be used for native rich text display within UILabels, UITextFields, and UITextView; however Text Kit contents are only partially accessible. The text content is read by VoiceOver, but the semantic markup is not. Thus Text Kit markup using NSAttributedText is not sufficient to meet semantic markup requirements at this time.

Use UI Web view and HTML markup to provide semantic markup.

Use the UIWebView element when information is required to have semantic markup. iOS has many ways to display rich static text, but only UIWebView offers accessible semantic markup. To use this technique, create a UIWebView element in the view. The UIWebView element can be as big or small as needed for rich text display. In the following code fragment, webview is an IBOutlet *UIWebView. In viewDidLoad, webview is loaded with an HTML string.

- (void)viewDidLoad
  {
     [super viewDidLoad];
     NSString *html = @"<html><body><h2>Sample Heading</h2><p>Sample paragraph.</p></body></html>";
     [self.webview loadHTMLString:html baseURL:nil];

Markup that reads well in the native Safari browser will also read well in a UIWebView.

Notes: Although UIWebView supports semantic markup, there are some disadvantages. Performance is not as fast as native UILabel and UIText elements, sometimes displayed results do not look exactly the same as fully native text.

Handle iOS UITableView contents

iOS UITableView implements a table as a single column with sometimes multiple pieces of data within the cell. (Multi column tables or grids are shown in a later example.) Contents on UITableView cells are typically summary information, images, or icons which can be selected to open a details page. The contents may read without further coding if they have accessible content or text. The developer is responsible for providing any needed modifications to what should be spoken and for setting the accessibilityLabel of the UITableViewCell. If the cells in UITableView can open a details page or perform another action, they must be labeled as buttons so it is clear they can be pressed. Note: This technique is also included in Checkpoint 502.3.3 Row, Column and Headers.

The following code sets a UITableViewCell label and button UIAccessibilityTrait on the cell in a UITableVIew:

- (UITableViewCell *)tableView:(UITableView *)tableView
cellForRowAtIndexPath:(NSIndexPath *)indexPath
  {
    // Get prior saved cell or create one
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"UITableViewCell"];
    if (!cell){
        cell = [[UITableViewCell alloc]
        initWithStyle:UITableViewCellStyleDefault       reuseIdentifier:@"UITableViewCell"];
      }

    [cell.textLabel setText:@"Visible Text"];
    cell.accessibilityLabel = @"Accessible Text";
    cell.accessibilityTraits = UIAccessibilityTraitButton;

    return cell;
  }

Provide semantic information in a grid (table)

iOS does not have a native UI element for a data grid similar to an HTML table. (Referred to here as a grid to distinguish from a UITableView.)

One alternative is to create an HTML table in an embedded UIWebView. HTML tables in a UIWebView provide built-in handling for VoiceOver. See example 3 for sample code to embed a UIWebView.

If content is displayed through native APIs in a custom grid display, it must provide navigation between cells and additional column and row information to provide context for the user. At a minimum, the user must hear the cell data, the column header if different than the previously heard column, and the row header or identifying row ID or number if different than the previously heard row. Until iOS provides a native UI element or APIs for a data grid, or some easy way to track previous cells, it is acceptable to provide the data, column header, and row identifier for each cell. Note: This technique is also included in Checkpoint 502.3.3 Row, Column and Headers.

In the follow code fragment, an array of UIAccessibilityElements is created to overlay a data grid. VoiceOver navigates through the UIAccessibilityElements and provides the mapped accessibility information.

/* Return the array of UIAccessibilityElements, or create if does not exist. */
- (NSArray *)accessibleElements
  {
    if ( accessibilityElements != nil )
    {
      return accessibilityElements;
    }
    accessibilityElements = [[NSMutableArray alloc] init];
    for (int iRow = 0; iRow < weatherTable.getRows; iRow++){
      for (int iCol = 0; iCol < weatherTable.getColumns; iCol++){
        NSMutableAttributedString *accessibleString = [[NSMutableAttributedString alloc] init];
        NSAttributedString *cellString = [[NSAttributedString alloc] initWithString:[weatherTable getCell:iRow :iCol] ];
        [accessibleString appendAttributedString:cellString];
        // Add the header information if not a header column/row
        if (iRow>0 & iCol>0){
          NSAttributedString *rowHeaderString = [[NSAttributedString alloc]     initWithString:[weatherTable getCell:0 :iCol] ];
          [accessibleString appendAttributedString:rowHeaderString];
          NSAttributedString *columnHeaderString = [[NSAttributedString alloc] initWithString:[weatherTable getCell:iRow :0] ];
          [accessibleString appendAttributedString:columnHeaderString];
        }
      element1.accessibilityFrame = CGRectMake(20+iCol*100,100+iRow*50,100,50);
      element1.accessibilityLabel = [accessibleString string];
      [accessibilityElements addObject:element1];
    }
  }
  return accessibilityElements;
}
/* Draw the visible grid of data. */
- (void) drawRect:(CGRect)rect
  {
    UIFont* font = [UIFont fontWithName:@"Arial" size:14];
    UIColor* textColor = [UIColor blackColor];
    NSDictionary* stringAttrs = @{ UITextAttributeFont : font,     UITextAttributeTextColor : textColor };
    for (int iRow = 0; iRow < weatherTable.getRows; iRow++){
      for (int iCol = 0; iCol < weatherTable.getColumns; iCol++){
        NSAttributedString* attrStr = [[NSAttributedString alloc]    initWithString:[weatherTable getCell:iRow :iCol] attributes:stringAttrs];
        // The visible grid matches the accessible grid
        [attrStr drawInRect:CGRectMake(20+iCol*100,20+iRow*50,100,50)];
      }
    }
  }
/* The container itself is not accessible, so the container view should return NO in isAccessiblityElement. */
- (BOOL)isAccessibilityElement
  {
    return NO;
   }
/* The following methods are implementations of UIAccessibilityContainer protocol methods. */
- (NSInteger) accessibilityElementCount {
    return [[self accessibleElements] count];
  }
- (id)accessibilityElementAtIndex:(NSInteger)index
  {
    UIAccessibilityElement *element = [[self accessibleElements]     objectAtIndex:index];
    return element;
  }
- (NSInteger)indexOfAccessibilityElement:(id)element
  {
    int iSelectedIndex = [[self accessibleElements] indexOfObject:element];
     return iSelectedIndex;
   }

Native iOS Examples

Alert sample app (IBM internal only)

Slider sample app (IBM internal only)

Eclipse techniques

Instructions: In addition to the General techniques, Eclipse applications must meet the following combination of techniques. This combination of techniques is deemed sufficient for meeting this checkpoint (1.3.1).

Windows-based (MSAA+IA2) techniques

Instructions: In addition to the General techniques, Windows-based applications must meet the following combination of techniques. This combination of techniques is deemed sufficient for meeting this checkpoint (1.3.1).


Most links in this checklist reside outside ibm.com at the Web Content Accessibility Guidelines (WCAG) 2.0. W3C Recommendation 11 December 2008: http://www.w3.org/TR/WCAG20/

Copyright © 1994-2017 World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University, Beihang University). All Rights Reserved.

Copyright © 2001, 2017 IBM Corporation