Attention Cascade users! It seems that Cascade recently made a change to the default setting for displaying asset names. If you prefer to see file names instead of titles or display names (which you should!), you’ll need to make a quick adjustment.

Here’s how you can revert to displaying file names:

1. Click on the user menu dropdown located at the top right corner of your screen. 
2. In the dropdown menu, select “Settings” from the list.
3. In the Settings menu, look for the checkbox labeled “Show asset’s Title or Display Name if available.” Make sure it is unchecked.
4. Once you’ve unchecked the box, click “Submit”.

That’s it! You’ve successfully reverted to displaying file names instead of titles or display names for your assets in Cascade.

If you ever wish to switch back to displaying titles or display names, you can revisit your settings and re-enable the option at any time. We don’t recommend that!

Brief:

The Interior template hero images/banners were originally designed to be more of a “masthead”, to be consistent throughout parts of a site. This is why we have the image for this section set in the options block. We have had many questions regarding some custom edits to the titles/image, which are limited here to keep this consistency across all interior pages within a folder or sub-site where a new options block is set. Previously we had an option to set the title to be either current folder’s display name OR the parent folder’s display name. This was causing some issues with multiple level items that were not intended to be sub-sites.

The Fix:

We have updated the way the titles are targeted for display. There is no longer a radio button selection for this in the options block. The titles in these banners/mastheads for interior pages are now targeted by the closest option block’s current folder. This title will trickle down throughout any sub items using the interior page template, until a folder is reached with a new options block. Any pages in that new level (along with the new options block) and deeper levels will have the new display name from the new option block’s current folder. This may be confusing to some. I will try to map it out below – in hopes i do not confuse any further. Please let me know if you have any questions.

For example:

/example-site-folder/ – has the display name – Example Site Folder.

/example-site-folder/options – options block is set here to get above display name on all interior pages

/example-site-folder/interior-page.html – display name displayed in masthead/banner – Example Site Folder

/example-site-folder/subfolder/interior-page.html – display name displayed in masthead/banner – Example Site Folder

/example-site-folder/subfolder/another-sub-folder/ – has display name – Another sub folder

/example-site-folder/subfolder/another-sub-folder/options – options block is set here to get above display name for  /another-sub-folder on all interior pages from here on out

/example-site-folder/subfolder/another-sub-folder/interior-page.html – display name displayed in masthead/banner – Another sub folder

Next Steps:

Publish any interior pages using the interior page template in your redesign site to catch this update.

If you have not noticed by now, the updated Secondary Navigation is now available in the new redesign templates

** You will need to republish any and all sn-config files you may have in your redesign site to grab the updated structure.

A couple notes on this.

1. We have extended the navigation to 3 levels instead of just 2.
2. There is no limit on the amount of items in the 2^nd or 3^rd sublevels of the menu. HOWEVER, please be mindful of how long your menus get vertically filled with navigation items in regards to forcing users to have to scroll down to view the whole sub menu on smaller laptop screens. We are hoping that providing this extra level will allow everyone to take a second look at their site hierarchy and organize their material into a user friendly experience.
3. A sub menu only kicks in if there are pages/folders (besides an index, sn-config, and options block) set to display in the nav, within the main folder at hand,
4. The new structure removes having main level items as buttons, which forced these to be links in the submenu. A menu item that has a submenu now is directly linkable from that primary level it is on, no more need for duplicate text. A separate button still remains with only the Arrow within. This is left for accessibility purposes/functionality.
5. Link text uses the Display Name field in the meta area of a page. There is a 70 characters limit on the nav item link text. This is NOT enforced on the Display Name field itself when entering text, but enforced on publish. PLEASE be mindful of this. If you Display Name is longer than 70 characters, it will get chopped. This limit should allow, still, a solid length of text, and keep your link text to no more than 3 lines.

Please publish, test your navigation, and let me know if you experience any issues or have any concerns.

We have added the “Blog Feed” feature to cascade. It can be added as a module in a new row, or added as a column widget in columns 6 cells or wider. Please follow the steps below to add to your page.

1. Select Blog Feed from the module selector or Widget Display list.
2. Fill in the name of the blog. This is the exact name in your url. For Example: “ows” in https://blogs.clemson.edu/ows/
3. Enter a numerical count of the amount of stories you wish to be displayed. Example: 1, 2, 5, 10, etc
4. Choose the blog format type. Default is “Basic Blog (No Images)”. This will not display any images. Posts with featured images will display a thumbnail image next to the listing if “Basic Blog (Display Images)” is chosen. The third option is a a standard list structure only showing and linking the titles of each post.
5. If applicable, fill in any categories. If multiple, separate by a comma.
6. If applicable, fill in any tags. If multiple, separate by a comma.

The new contact module is ready to implement on your pages.

**Remember, if you have used the module previously, you will have to update your pages to this new setup.

1. Navigate to your widgets folder, then click “Add Content” in the top nav
2. Navigate to Components > Widget.
3. Select “Contact Module” from the widget type.
4. Enter your desired data into the provided fields.
   1. These are the same fields in the previous set up, but your data will not be preserved from the previous setup.
   2. Recent updates to these fields were the abilities to toggle having either a custom link or a website contact and toggling on or off the social links.
5. Save and Publish your new widget
6. Next, navigate to your page and click “Edit”
7. Scroll down towards the bottom of the editor window, and you will see a new group labeled “Widget Module Area”. See attached screenshot.
8. Select Yes to display the area.
9. Choose the recently made widget from the widget chooser.
10. Repeat steps 6-9 per page as necessary.
11. Publish your page/s.
    1. Once your page has this setup published once, publishing all your pages will not be required for each update. you will only need to edit and publish the widget for it to reflect updates across all the pages!

Only the Contact module widget will work here, the other widget types will not display here and only will display in the left column. And vise versa.  The contact module widget will not display in the left column. Warning messages will display on your page if you accidentally assign the wrong widget type to an area.

We hope you guys find this new addition helpful, useful, and easy to implement. Please reach out with any questions, concerns, or issues.

We found a situation where a user may copy a folder from an old site. This is great in helping get your content over, but will not give you the proper meta data on the folder. To combat this, please create all folders from your new redesign site and copy any potential files like images into the newly created folder to ensure the proper meta data is there. This meta data is needed to help build the navigation.

I wanted to make everyone aware of a recent update to the Interior Page Template Hero Image. We were brought aware of the idea that it could be difficult to find that many images for each interior page. These interior page banner images were originally meant to be more of a “masthead” for the page and be consistent throughout each of your folders/sections/departments of your site. This is why we have made the switch to set this on the folder level instead of per page. You will still set images on landing page templates, this only affects Interior Pages.

Prior:

• The Hero Banner Image was set per page

Now:

• The Hero Banner Image is set in the options block

**NOTE: Any built interior pages prior to this email will not carry over the set image. Please update your options block with your desired banner image to reflect the change and republish any interior pages to reflect the update.

Web Forms

Forms are commonly used to provide user interaction on websites and in web applications. For example, login, requesting information, registering, commenting, and purchasing. The same concepts apply to all forms, whether they are processed client or server-side.

Aside from technical considerations, users usually prefer simple and short forms. Only ask users to enter what is required to complete the transaction or process; if irrelevant or excessive data is requested, users are more likely to abandon the form.

• Labeling Controls:
   Use the <label> element, and, in specific cases, other mechanisms (e.g. WAI-ARIA, title attribute etc.), to identify each form control.

  <label for="firstname">First name:</label>
  <input type="text" name="firstname" id="firstname"><br>
  
  <input type="checkbox" name="subscribe" id="subscribe">
  <label for="subscribe">Subscribe to newsletter</label>
  

  The title attribute can also be used to identify form controls. This approach is generally less reliable and not recommended because some screen readers and assistive technologies do not interpret the title attribute as a replacement for the label element, possibly because the title attribute is often used to provide non-essential information. The information of the title attribute is shown to visual users as a tool tip when hovering over the form field with the mouse.

• Grouping Controls:
  Use the <fieldset> and <legend> elements to group and associate related form controls.Grouping related form controls makes forms more understandable for all users, as related controls are easier to identify. It also makes it easier for people to focus on smaller and more manageable groups rather than try to grasp the entire form at once.
  The <fieldset> element provides a container for related form controls, and the <legend> element acts as a heading to identify the group.The legend for a group of controls can also highlight common attributes of all controls, for example, to advise that all fields in the group are required.

  <fieldset>
  <legend>Output format</legend>
    <div>
      <input type="radio" name="format" id="txt" value="txt" checked>
      <label for="txt">Text file</label>
    </div>
    <div>
      <input type="radio" name="format" id="csv" value="csv">
      <label for="csv">CSV file</label>
    </div>
    […]
  </fieldset>

  Depending on the configuration, some screen readers read out the legend either with every form element, once, or, rarely, not at all. To accommodate this consider the following:

  • Make the legend as short as possible for situations in which it is read together with the label each time.
  • Make the individual labels sufficiently self-explanatory for situations in which legends are not read aloud, without repeating the legend in every label.
• Form Instructions: Provide instructions to help users understand how to complete the form and individual form controls.
  Provide instructions to help users understand how to complete the form and use individual form controls. Indicate any required and optional input, data formats, and other relevant information.Important: Screen readers often switch to “Forms Mode” when they are processing content within a <form> element. In this mode they usually only read aloud form elements such as <input>, <select>, <textarea>, <legend>, and <label>. It is critical to include form instructions in ways that can be read aloud. This will be explained further below.

  In addition to overall instructions, it is also important to provide relevant instructions within the labels of the form controls. For example, to indicate required input fields and data formats in the text of the labels.

  <label for="expire">Expiration date (MM/YYYY): </label> <input type="text" name="expire" id="expire">

• Placeholder Text: Provides instructions or an example of the required data format inside form fields that have not yet been edited by the user.Placeholder text is usually displayed with lower color contrast than text provided by users, and it disappears from form fields when users start entering text. If the placeholder text contains instructional information or examples that disappear, it makes it more difficult for users to check their responses before submitting the form.While placeholder text provides valuable guidance for many users, placeholder text is not a replacement for labels. Assistive technologies, such as screen readers, do not treat placeholder text as labels. Moreover, at the time of writing this tutorial, placeholder text is not broadly supported across assistive technologies and not displayed in older web browsers.

  <div> 	<label for="search">Search:</label> <input type="text" name="search" id="search" placeholder="e.g. Apple Pie"> </div> <div> 	<label for="email">Email: </label> <input type="text" name="email" id="email" placeholder="joe@example.com"> </div>

• Validating Input: Validate input provided by the user and provide options to undo changes and confirm data entry.In addition to providing instructions, validate user input to help users avoid mistakes. HTML5 defines a range of built-in functionality to validate common types of input, such as email addresses and dates. In some situations, such as validating custom controls or supporting legacy browsers, additional scripting may be necessary to validate user input.

  Forms frequently include required input that needs to be clearly identified using labels. Also, the requiredattribute can be added to form controls, to programmatically indicate that they are required. Most current web browsers support this attribute and will communicate missing required input to the user, using standard web browser dialog mechanisms. These dialogs are expected to respect the settings and preferences of the user in the web browser (and operating system), such as default font-size, colors, and language.

  <label for="name">Name (required): </label> <input type="text" name="name" id="name" required aria-required="true">

  The aria-required attribute informs assistive technologies about required controls so that they are appropriately announced to the users (as opposed to validating the input). Most current web browsers automatically set its value to true when the HTML5 required attribute is present. In this example, it is provided redundantly to support web browsers that don’t communicate the required attribute to assistive technology.

  Validation should aim to be as accommodating as possible of different forms of input for particular data types. For example, telephone numbers are written with different separators and digit groupings. Your form will be easier to use if it can interpret multiple notations. Also, it is helpful to be liberal with input. For example, postal codes aren’t confined to just numbers in some countries, so using an input of the type number can easily become a problem for many of your website users.

• Multi-Page Forms: Divide long forms into multiple smaller forms that constitute a series of logical steps or stages and inform users about their progress.
  Where possible, divide long forms into multiple smaller forms that constitute a series of logical steps or stages. This helps make long forms less daunting and easier to understand, particularly for people who are less experienced using computers or who have various cognitive disabilities. The following basic principles should apply for multi-step forms:
  • Repeat overall instructions on every page.
  • Split the form up according to its logical groups of controls. For example, in an online shop, shipping and payment information are typically separated.
  • Make it easy to recognize and to skip optional stages. For example, highlight optional steps in the main heading of the web page and provide an option to skip.
  • If possible, the first step of a form should explain how many steps will follow. Each step should inform the user about the progress they are making.

Caption and Summary

Captions and summaries provide information that can help users find, navigate, and understand tables. While they are not required in every case to meet WCAG 2.0, captions and summaries are fairly straightforward ways to provide such information that is often needed.

• A caption functions like a heading for a table. Most screen readers announce the content of captions. Captions help users to find a table and understand what it’s about and decide if they want to read it. If the user uses “Tables Mode”, captions are the primary mechanism to identify tables. The caption is provided by the <caption> element.
• A summary conveys information about the organization of the data in a table and helps users navigate it. For example, if a table has an unusual structure (as in the examples below), information about what content can be found in which row or column can be provided to the user. A summary is usually only needed for complex tables.

If both caption and summary are provided for one table, the summary should not duplicate information present in the caption.

If you’re not a screen reader user, let’s pretend that you are for just a moment. You’re going to a web site to find out where the biology 205 class is going to be held. You go to a web page that has this information, and this is what you hear:

Table with 10 columns and 7 rows. Department Code, Class Number, Section, Max Enrollment, Current Enrollment, Room Number, Days, Start Time, End Time, Instructor, BIO, 100, 1, 15, 13, 5, Mon,Wed,Fri, 10:00, 11:00, Magde, 100, 2, 15, 7, 5, Tue,Thu, 11:00, 12:30, Indge, 205, 1, 15, 9, 6, Tue,Thu, 09:00, 10:30, Magde, 315, 1, 12, 3, 6, Mon,Wed,Fri, 13:00, 14:00, Indge, BUS, 150, 1, 15, 15, 13, Mon,Wed,Fri, 09:00, 10:00, Roberts, 210, 1, 10, 9, 13, Mon,Wed,Fri, 08:00, 09:00, Rasid.

After listening to this information, do you have any idea where biology 205 is supposed to be held? Probably not. When you listen to tables straight through, without going into table reading mode in a screen reader, this type of information can be quite confusing. Even when you do go into table reading mode, it can still be confusing if the table is not marked up properly.

Layout Tables vs. Data Tables

There are two basic uses for tables on the web: data tables and layout tables. The original intended use of HTML tables was for tabular data. A table is a data table when row headers, column headers, or both are present. For example, here is a simple data table:

Tables are also commonly used for page layout. Layout tables do not have logical headers that can be mapped to information within the table cells. Layout tables were traditionally used to overcome limitations in visual presentation and layout using HTML. With CSS, however, there is much more flexibility in controlling page layout, so it is best to not use tables to do this. Using CSS results in cleaner and more simple HTML code, better end user adaptability, and few potential accessibility issues.

It is sometimes suggested, even by some accessibility advocates that layout tables are bad for accessibility. In reality, layout tables do not pose inherent accessibility issues. There are certainly many worse things that you could do in terms of accessibility. People with all kinds of disabilities can easily access layout tables, as long as the tables are designed with accessibility in mind – ensuring proper linearized reading order, content scaling, etc.

Layout Table Linearization

Content linearization refers to the order of the content when all formatting is removed. For both data and layout tables, the order in which content is presented can affect its meaning. Many web sites use tables for layout, and most of them use spanned rows and columns to achieve formatting effects. The end result is that the linearized reading order may not be the same as the visual reading order. This can lead to confusion on the part of people who access the linearized reading and navigation order, such as individuals who use screen readers or who navigate with keyboards.

Screen readers essentially ignore the fact that the content is inside of a table. The screen reader just reads the content in the literal order that it appears in the code. If the literal order of the content in the code is logical, then your linearized reading order is logical.

Screen readers treat layout tables and data tables very differently. For layout tables, they simple read the content of table based on the source code order. For data tables, however, they will identify the presence of the table including number of columns and row, provide table navigation functionality, read row and column headers, etc.

So how does a screen reader know if a table is a data table or a layout table?

They perform some analysis of the table markup and structure to ‘guess’. Because of this, it’s vital that data table markup, such as <caption>, <th>, etc. are NEVER used within layout tables, otherwise the screen reader may incorrectly present the table as a data table causing increased overhead and confusion.

Layout Table

When author’s use tables for layout, they are typically doing so to get more precise and (supposedly) flexible control over the positioning of elements within the page. When doing so, layout tables typically define pixel values to attempt to control exact positions. Because there is an immense range of end user browsers and devices, ranging from text-only mobile browsers to large-screen, high definition displays, defining pixel-based sizing is very limiting.

A primary concern of layout tables is their lack of flexibility for accommodating end-user content adjustments, primarily text sizing by users with low vision. If text within a pixel-sized table cell is enlarged by the end user, this can cause readability issues, especially if the text can no longer fit within the pixel dimensions defined. This may result in horizontal scrollbars, text bleeding out of the cell and overlapping other page components, etc. If using layout tables, ensure that the structure of the table allows end user customization and text scaling.

It is possible to create all kinds of nested tables and unnecessary rows and columns, using spanned rows and columns in every which way, until the table hardly looks like a table at all anymore. All of this may be invisible to sighted users if the table borders are set to zero, but blind users will “see” it all. Their screen readers may inform them of the number of rows and columns in the table. When they try to navigate from one area to the other within the table, they may become disoriented. The rule of thumb here is, the simpler the better.

Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are recommended in order to retain the defined meaning of the HTML table elements and to conform to the coding practice of separating presentation from content.

Data Tables

The purpose of data tables is to present tabular information in a grid, or matrix, and to have column or rows that show the meaning of the information in the grid. Sighted users can visually scan a table. They can quickly make visual associations between data in the table and their appropriate row and/or column headers. Someone that cannot see the table cannot make these visual associations, so proper markup must be used to make a programmatic association between elements within the table. When the proper HTML markup is in place, users of screen readers can navigate through data tables one cell at a time, and they will hear the column and row headers spoken to them.

Table Captions

Data tables very often have brief descriptive text before or after the table that indicates the content of that table. This text should be associated to its respective table using the <caption> element. The <caption> element must be the first thing after the opening <table> tag.

Identify Row and Column Headers

A critical step toward creating an accessible data table is to designate row and/or column headers. In the markup, the <td> element is used for table data cells and the <th> element is used for table header cells. Going back to our original data table example, the column headers for this table are Name, Age, and Birthday. The row headers are Jackie and Beth. Also note the associated caption.

Table headers should never be empty. This is particularly of concern for the top-left cell of some tables.

Associate the Data Cells with the Appropriate Headers

Now that we’ve created headers, we need to associate the data cells with the appropriate headers.

The scope attribute

The scope attribute identifies whether a table header is a column header or a row header. Here is the markup for the table, using the scope attribute:

<table>
<caption>Shelly's Daughters</caption><tr>
<th scope=”col”>Name</th>
<th scope=”col”>Age</th>
<th scope=”col”>Birthday</th>
</tr><tr>
<th scope=”row”>Jackie</th>
<td>5</td>
<td>April 5</td>
</tr><tr>
<th scope=”row”>Beth</th>
<td>8</td>
<td>January 14</td>
</tr>

</table>

The scope attribute tells the browser and screen reader that everything within a column that is associated to the header with scope="col" in that column, and that a cell with scope="row" is a header for all cells in that row.

All <th> elements should generally always have a scope attribute. While screen readers may correctly guess whether a header is a column header or a row header based on the table layout, assigning a scope makes this unambiguous.

Scope will apply even if the table is complex with multiple levels of headers (such as in spanned cells). The scope of a table header will apply to all cells over which that header spans.

In this example, the “by birth” row header has a scope of row, as do the headers with the names. The cell showing the age for Jackie will have 3 headers – one column header (“Age”) and two row headers (“by birth” and “Jackie”). A screen reader would identify all of them, including the data cell content (e.g., it might read “by birth. Jackie. Age. 5.”).

Despite being standard markup for tables for many years, some screen readers still do not fully support complex tables with spanned or multiple levels of row and/or column headers. When possible, try to ‘flatten’ the table and avoid spanned cells and multiple levels of header cells.

The headers and id attributes

Another way to associate data cells and headers is to use the headers and id attributes. This method is NOT generally recommended because scope is usually sufficient for most tables, even if if the table is complex with multiple levels of headers.

In extremely complex tables where scope may cause table headers to apply to (or have a scope for) cells that are not to be associated to that header, then headers and id may be used. In these cases, while headers and id might make the table technically accessible, if there are multiple levels of row and/or column headers being read, it will not likely be functionally accessible or understandable to a screen reader user.

With this approach, each <th> is assigned a unique id attribute value. Then, each and every <td> cell within the table is given a headers attribute with values that match each <th> idvalue the cell is associated to. The values are separated by spaces and should be listed in the order in which a screen reader should read them. If using headers/id in the example above, the cell for Jackie’s age might be marked up as <td headers="birth jackie age">5</td>).

Again, it should be emphasized that this method is more complex, uses much more markup (and potential to become broken), and is rarely necessary (use scope instead).

Use Proportional Sizing, Rather than Absolute Sizing

The rule that applies to layout tables also applies to data tables. Let the browser window determine the width of the table whenever possible, to reduce the horizontal scrolling required of those with low vision. If cell widths need to be defined, use relative values, such a percentages, rather than pixel values. Defined cell heights should generally be avoided so the cell can expand downward to accommodate its content – something especially useful for users with low vision that may enlarge text content.

Other table markup

Summary

The summary attribute of the <table> tag may be used to provide a summary of a data table structure (not content). Support for summary varies, but in general, it is screen reader specific (it’s not accessible to anyone else) and is not well supported. Additionally, the summaryattribute is not part of the HTML5 specification. In general, if a table is so complex that it needs an explanation of how it is structured, it probably is not very accessible and should probably be simplified. For these reasons, we do not recommend the use of summary. If it is used, it must never be used for layout tables.

thead, tfoot, and tbody

The thead and tfoot elements define header and footer rows for tables. They provide no accessibility functionality and are generally only of use when a long table is printed – the head and/or foot rows will repeat at the top or bottom of each printed page. Similarly, the tbodyelement defines the body content of a data table (meaning anything that’s not a thead or tfood). Again, this element does not provide any additional accessibility benefit, but there is no harm in using it for table styling or other reasons.