This article will show you how to insert a table in the Editor widget.
Important Notes
- You may use the Table widget instead of the Table Insert tool in the Editor widget. The Table Widget is a fairly simple tool that is not as robust in table styles and options as the Table Insert tool in the Editor Widget.
- Follow Table Compliance and Accessibility Best Practices to ensure Americans with Disabilities Act (ADA) compliance.
- We encourage you to use multiple Editor widgets when you need to stack side-by-side on a page, rather than using tables within the editor. Tables should only be used when displaying data and not for page layout. Using tables for page layout will cause your content to display incorrectly on mobile devices.
- Learn how to add code to the editor widget to make your tables more mobile-responsive.
Instructions
- Log in to your website solution
Note: Website preferences may change what this looks like, but adding "/admin" to your website's URL will take you to a sign-in screen for administrative login - Navigate to your desired page
- Ensure that the Live Edit state is toggled to ON:
- Click on the Editor widget you're adding a table to:
- Click the Insert Table button on the Editor widget toolbar:
- Choose your desired number of columns and rows with the column/row selector:
- Left-click into any cell to view the table menu:
-
Header Row: Turn on to create a table header row that spans all of the columns
Note: This will ensure that the top row of the table applies to all of the data, and screen readers will apply it to all of the content.
-
Table Styles: Turn on Alternate Rows:
-
Header Row: Turn on to create a table header row that spans all of the columns
- Add header information to the table header row:
Note: This information needs to apply to all of the data that will be placed in each column. For instance, do not place “activity” in row one if you will place “shoe” in the related column. - Fill in the rest of the table with content:
Note: Be sure to alphabetize the primary information (in this case, the entries in the Activity column). - Click the Done Editing button to exit the editor:
- Click the Save button to save your work:
Feedback About the Article
Let us know what was helpful or not helpful about the article below.3 comments
This article, if I understand it right, is very confusing - on multiple levels. You said:
The Table Widget might not be robust enough, but it produces tables that are in compliance with the mobility, accessibility and usability. It is EVERYTHING that the Editor Widget Table is NOT. Yet, you recommend to use it. I ran it by the CivicPlus support and they went even step further than you did - they strongly recommended to use the Editor Widget Table, implying that the Table Widget will be removed from the system soon. This has prompted me to write a reply. Let's look at it from all three prospective - mobility, accessibility and usability.
Let's start with the Editor based table. Here is how it looks on a desktop. We can observe seven columns and multiple rows:
And here is how it looks on the phone (in this case it's iPhone 13 Pro Max). We can observe only five columns, so we would have to do horizontal scrolling and we'd do it ONLY if we know there is something else in this table we need to see.
So, in this case, the usability and mobility (responsiveness to the screen) are NON-existent. When I turned on the screen reader, the reading didn't make much sense either - it would read as if a blind person somehow memorized the all the headers and knows exactly what it means when they hear for example, this line:
This makes the narratives completely meaningless. So the accessibility part for this table is missing in action as well. The widget failed to render a table that is mobile, usable, accessible.
Now for the comparison, let's observe a table built with the Table Widget.
Here is that table on the desktop screen - looks fine and all the seven columns are visible:
Let's observe the same table - how it looks on the phone.
We can observe here that the table has realigned itself to the screen and NO horizontal scrolling needed. Here is our usability and mobility in action. But, also, each value is displayed with a CORRESPONDING HEADER. And that's exactly how the screen reader reads it: it names the street and then it goes on naming the attribute (header) + value (cell data). The whole text to speech makes perfect sense, just as it should when a web page is in compliance with the accessibility requirements.
The key here is to take your time and actually LISTEN to the screen reader - if it makes any sense at all. Only then we can claim that the web page and the table on it are accessible. I certainly do hope that CivicPlus will NOT remove the only widget (Table widget) that is in compliance with the table accessibility, mobility, usability.
Can Civic Plus respond to this post from Inna Young? It was also suggested to me by Tech Support to NOT use the table widget, but rather create a table within the Editor widget. But as Inna pointed out, the Table widget seems to work better and seems to be better with accessible compliance.
Yes, CivicPlus, please respond to Inna Young's post. I've been struggling with this issue because tables created in the Editor widget look terrible on mobile. There's no way my co-workers want their tables to look this bad. They get complaints from our site's visitors!
Please sign in to leave a comment.