I have an HTML data table that I am trying to make accessible. It works well enough with NVDA and Jaws. But the context of the data is such that it makes more sense to be read column by column rather than row by row as screen readers default to.
Is there a way to make sure the table is read column by column?
You don’t have to do anything, except marking it up correctly (i.e., what the headers are, and possibly what their scope is).
Just like sighted users don’t read the whole content strictly from left-to-right, top-to-bottom, screen reader users don’t let the page read out to them from the beginning to the end -- all users scan the content and jump on the page.
Inside a table, screen readers typically allow moving from cell to cell, to beginnings and ends of columns and rows, etc. See for example the commands for reading tables with JAWS.
If you think it’s not easily understood how the data is organized, consider adding a description in the caption element, e.g., something like "The first row gives the dates, each column contains the data for a day".
Related
I'm responsible for remediating a PDF that has been generated by a third-party, proprietary system for which I have no access to the layout or design. The goal is to pass the adobe acrobat DC accessibility checker before publication.
Some of the tables in the PDF span multiple pages horizontally (i.e. with a page break at column 4 of 7). Thus far, I have designated each piece of text content as a "Cell" and grouped those into a "Table Row" tag and defined each header and sub-header as a "Table Header Cell".
However, Acrobat DC seems to get confused as to the relative size and spacing of each table element. It is creating phantom column headers and rearranging or combining rows in order to fit the appearance of a more standard layout PER PAGE. But since I need one cohesive table to span TWO PAGES, this is breaking my accessibility.
Depending on how I nest my table elements, I get a table layout like one of the two examples below:
Example when including blank cells for multi-column header rows
Example when defining the column span of multi-colum header rows as "7"
As you can see, the layout is not uniform and does not pass regularity checks. Plus, as I add more rows with several blank cells, the table editor produces an error that reads:
"Unknown Table Structure Encountered"
The only way I have managed to remove this error, is to exclude the bolded main-section sub-headers from the tag structure entirely, but I cannot just leave them as untagged content and pass the checker.
Please help.
Signed up just to comment to
Kevin, thanks for replying. Because of the malformed grid, I cannot even click on the cells on Page 2 in order to associate headers. Is there a way to define table structure without using the Table Editor mode? – Glamador Apr 3 at 12:27
but don't have the rep yet to do so:
Glamador - Knowing it can't help you half a year ago but might in the future: I encountered this in a document this week and figured out the "Why" and how to get the Table Editor back, but not the "Easiest/best way to solve" the tagging in Acrobat. This issue is denying you Table Editor is with the table header (TH) cell you created that spans multiple pages.
So if you set a table header cell to something like Row Span: 7, and 3 of those are on the second page Acrobat will give you the "Unknown table structure encountered. Please retag this table using the Reading Order Tool to possibly fix the problem." error any time you try to use the Table Editor on the table that has that [table header cell with a multi-page row span/I'm not working with but assume column span too].
To get your Table Editor use back (not solving the tagging of accessibility, but to quit getting that error on your table,):
Go to your tags
Create a new empty Table Header Cell
Drag the content displayed in the tag from the problem TH to your new TH
Delete the [multiple page row/column spanning, but now empty] problem TH
Repeat if you did this in multiple TH in the same table
You can now use Table Editor again
Note: Because you can't use the Table Editor once these problem headers have been created you can't use it to see which TH's you have set to span multiple pages, or see those row/column spans, so you're going to have to just look at your document if you went through tagging and are going back and checking later and figure out which are the likely problem headers to replace. If you create that header span again in the table that goes across multiple pages you'll be unable to use the Table Editor again until you delete that tag with the page spanning issue.
I haven't found if you can combine TH Row Span settings with IDs/Associated Header Cell IDs and have the user software identify both, so I've been doing the tedious ID association on large but simple tables as my "It's tagged correctly" option, but unfortunately it isn't nearly as fast and easy as Row Spans.
You can edit the tag's object properties by right-clicking on the tag and then you can add an ID there if it doesn't already have one. Be sure each data cell is associated with a header cell. PAC's screen reader preview will also give a good view of the layout to help you get everything associated correctly.
I am creating a data-merge document in InDesign.
There are various tables that I've created which only show as many rows as there is actual data in the field, through some creative table and cell styles.
Now I've been asked to only have an entirely separate table only show if there is information in any of those fields.
I'm at a total loss. With the way the current structure is set up, I can cause it to not display any text, but it still shows empty header cells and one line of empty row cells.
Pre-DataMerge, with the data fields
Post-Datamerge, with the resulting empty cells
Any creative ideas to hide that table? I was thinking there might be a way to hide the entire text field, if not the table. Maybe a script? I tried one that deletes blank tables, but that didn't seem to work after the data-merge was run.
I am not sure you can get that level of processing with InDesign datamerge. You could think of a script to post remove those tables or use a dedicated plugin such as Easycatalog that can take care of such empty items natively.
In several notes applications, instead of handling related data as separate documents, if the size of the data is small (less than the 32k limit), I'll make several multi valued fields and display it in what I call a "List Panel". It's a table where each column displays one multi-value field. Since fielda(1) goes with fieldb(1) that goes with fieldc(1) there is a concept of rows. (I did a similar thing in my auditing routine discussed here )
It is always assumed that each field has exactly the same number of elements.
All the multi-value fields are then stored on the single document. This avoids several coding conventions that made my eyes bleed like having date changed, who changed it, new value fields for each field we wanted to audit. Another thing that this kept to a minimum was having to provide multiple fields for the same thing that locked you into a limit. Taxrate1, Taxrate2, Taxrate3, etc...
In my "Listpanel" the first column is a vertical checkbox. (One for each element in my lists) This is so I can select one item to bring up and edit, or select multiple values to delete "rows" or apply some kind of mass change to them.
What would be the best way to handle this under xPages to get this functionality? I tried making a table but am having the devil of a time to get the checkboxes to line up with their corresponding data items.
Views and dojo-grids seem to assume we're using a document for each row.....
This TableWalker may provide what you want http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Tutorial-Introduction-to-XPages-Exercise-23
It was created when XPages was all very new, so it's SSJS rather than Java. But if you're comfortable wiith Java, converting it probably won't be a challenge.
You could use a repeat control to display the values and build a table using the table row tags in the repeat. You would want to calculate the id of the checkbox to be able to take an action on that selected row. The repeat var would be just one of your multi-value fields and you use the index of the repeat to get the value for that row from the other multi-value fields.
I cannot figure this out for the life of me.
I want a report object where each page (no matter how big, small, etc) corresponds to one record in the underlying source query (each record corresponds to a Client along with some financial data).
I've tried grouping by Client, inserting page breaks, trying to integrate forms, etc. Nothing. Everything just combines together into one giant list -- there's no separation per page.
Select the Group Header and view Properties (F4). It should be named something like GroupHeader0. For the Force New Page attribute, select Before Section, After Section, or Before & After Section.
The hardest part of this for me was finding the correct item to click that has the Force New Page attribute -- it isn't the field itself, but the Section (which is named "GroupHeaderX" by default).
I've been tasked with learning Lotus Domino Designer - not sure what I did in a previous life, but it must have been pretty bad... - and was wondering how to do a lookup on a database to get some values for selections. As this information could potentially be used in a lot of the applications, I'd prefer it only to be in the one place.
I gather I can use #DBColumn, but what happens if an entry in that lookup changes? If the unique value of the lookup is the text, then the relationship would be broken, wouldn't it? Is there any way of mimicing the idea of relational lookups?
I'm assuming I'm looking at Lotus development from the wrong angle, as this seems to be a real limitation of look ups.
I haven't found any decent learning material on the interwebs, so would appreciate any help.
Ta
You would want to store a unique ID along with the textual value in the source database (not unlike what you would do in an RDBMS). Then, only store that ID in any referencing documents, and use a computed-for-display field to lookup the display value. (There is a performance consideration here - and you could "de-normalize" the data and store the ID and text value in the referencing documents, and do some asynchronous work to keep the values in sync - eg: using a scheduled agent that runs every night or every week).
If DB1 has the key values and DB2 has the documents which will reference these values, then in the form in DB2, you would still do a #DbColumn to lookup your value list. In the lookup view in DB1, concat the text value and ID with a pipe separator (textField + "|" + ID) in the first column. That will tell Notes to store only the ID value (what follows the pipe is the "alias" and is what will be stored).
Note: I would avoid using #DocumentUniqueID as the unique ID for these values, as the Document Unique ID will change if the documents are copied and pasted, or the entire database is copied, etc. You can use the #unique formula function in a computed-when-composed field to generate something close to a unique ID (almost like an identity column in sql).
If you need relational properties, look for non-Notes solutions. It is possible to get some relational behavior using document UNIDs and update agents, but it will be harder than with a proper relational backend.
Your specific problem with referencing to a piece of text that might change can to some extent be resolved by using aliases in the choice fields. If a dialog list contains values on the form...
Foo|id1
Bar|id2
...the form will display Foo but the back-end document will store the value id1 - (and this is what you will be able to show in standard views - although xpages could solve that). Using the #DocumentUniqueID for alias can be a good idea under some circumstances.
It depends on where your using the data. The #DBLookup or #DBColumn will work in Lotus Notes fields if the fields are set to be computed for display. That way they always get the most up to date information when you open the form etc.
If you make it so the data is saved on to the document then you will have to write some update code when you need to refresh the values.
The Lotus Notes help files for designer are pretty good, have a look at that.
SM
You could use a key or alias to store the relationship to your lookup value so if the value itself changes, the connection remains because the alias is intact. For example, if your lookup values were being stored as a collection of documents, I'd have the #DBColumn retrieve Document UNID|lookup value pairs. When in display mode, you could then retrive the value using #GetDocField. If the lookup values are in a different database, then you'd have to retrieve them for display using #DBLookup and construct a view that is keyed off of the UNID or whatever key you decide to use.The only drawback to this technique is that you wouldn't be able to display the field value in views as the actual value isn't stored in the document, just a reference to it. Using XPages, though, you COULD map the relationship into a dynamic datatable just like you would in a truly relational system.
It's tricky, but using LEI, you could also use Notes to front-end a relational backend system, also giving you the dynamic relationship you desire in your lookups.
Hope this helps!
The content of the lookup can change freely. A problem only arises (as it would on any other platform in the same circumstances) if the lookup key changes. You need to use a key that won't change. Human-readable text is an advantage, but if you want to be able to change your key description from, say, "Divisions" to "Business Units" and still have lookups work, you need to use an alias of some kind, which will presumably be mapped to your text description and only used internally. #Unique is pretty good for this, and gives a shortish key, if that is important to you. #DocumentUniqueID is most reliable, but as Ed pointed out, will change (must change - it's a new document) if you copy/paste or make a non-replica copy. This is easy to get around, though. Create a Computed-when-composed field (called, say, "LookupRef") on the form you are using for your reference document with the formula "#DocumentUniqueID". That will capture the ID at the time of creation, and it will not change on copy/paste etc. Use that as your key.