Help file suggestion

[Pelle]

Yes, the problem is in the <td> ... </td> instead of <th> ... </th> tags used for the header row in each of the tables.

Looks like around 700 tables that needs manual editing. I can only say: maybe.

Found a couple other small typos for you:

OK, I will try to fix them.

[Quin]

Looks like around 700 tables that needs manual editing. I can only say: maybe.

Whoa, that's a lot of tables! Thanks for your willingness to consider fixing them Pelle, just keep in mind not all has to be done in one go even tiny improvements are appreciated much by us screen reader users . I understand Pelles C is a labor of love and not of profits so doing manual work like this is probably low on the priority list

[John Z]

Hi Quin,

Hi,
Yes, this reads great! Something like this for the tables in the help file would be fantastic!

Here is the 'real' test, Both tables modified and inserted into a .CHM file.  Please test to be sure these work for you.  If they work, I'll post the revised table files for Pelle to consider using.  If he agrees and has the time, he is very busy getting another release candidate ready, they might be in the next release.

It is posted as a 7z file because in some cases download .chm files are prevented or require unblocking.  Also note that .chm files do not work well if on a network drive, local drive only.

John Z

I just read the prior postings on this - looks like there may be an easier way.  td vs th but I don't know that all tables have a header row, these two did not afaik....

Well please test anyway just so I know.

[Quin]

Hi John,
yep, these read perfectly as well!
Thanks for all your work!

[John Z]

Hi Quin,

Please test this help file.  It uses the alternative suggestion replacing all 'td' with 'th'.
If this does work for the reader is probably is easier to do than adding a <thead> </thead> section.

John Z

[Quin]

Hi John,
Yes, this is recognized as a table, but it's not perfect. The table headers are recognized as the top item in the header, and my screen reader announces these when I switch  columns. SO, for example, in the ascii table, the column label for column 9, no matter what row I land on, is "128". I think this is why the <thead> elements are so useful. I understand that adding the <thead> elements is a huge undertaking though, and would be more than happy to have the tables looking like this in the next version of the help file, and have the <thead> elements added more slowly over time, if Pelle desires.

[John Z]

Hi Quin,

The two tables I've used for testing had no column titles/headers at all, so the for the first test  I added them, then for the second test I just used what was there.

I looked in the help file further and see many tables do have headers even though they are not defined as such.  So I'll do one more test on one of those that already has a header but is not using <th .

If global replaces works well on it then it might still be possible to use search & replace en mass, and not a big edit job adding <thead>      </thead>.

Will post for testing when done,

John Z

[John Z]

Hi Quin,

Next test help file attached.  I do notice visually that changing all <td to <th results in all bold text. So that is a drawback.

There are two version of two different files.  _top means only the top <td changed to <th and in both of these files the top was actually a header for the rest.  Entries with _all used a global search and replace.


I found 662 tables in 473 files approximately.  Unfortunately it appears the best way will be to edit each individually.  Global search and replace isn't going to give great results for everyone.

John Z

[Quin]

Hi John Z,
Thanks for your work! Both versions read the exact same to my screen reader in terms of the columns
The one thing I noticed though is that the Associativity column only has a value in the first row for every section, not every row. Is this intentional?

[Quin]

Hi Pelle,
Got a few more typos for you:
In the CC reference: "Pelles compiler driver coordinate the execution of" should be: "Pelles compiler driver coordinates the execution of".
In the C Constant expressions section: "Such a constant expression evaluate to one of the following" should be: "Such a constant expression evaluates to one of the following".
In the C declarations section: "A declaration declare at least a declarator, a tag, or the members of an enumeration." should be": "A declaration declares at least a declarator, a tag, or the members of an enumeration."
Thanks!

[Pelle]

Hi Pelle,
Got a few more typos for you:

Hi Quin,

OK, I will fix them. Thanks.

[John Z]

The one thing I noticed though is that the Associativity column only has a value in the first row for every section, not every row. Is this intentional?

Yes that is how the table appears, in a given section where the Associativity is the same it is only listed on the first entry of the table section.

John Z

[Quin]

The one thing I noticed though is that the Associativity column only has a value in the first row for every section, not every row. Is this intentional?

Yes that is how the table appears, in a given section where the Associativity is the same it is only listed on the first entry of the table section.

John Z

Ah I see, thanks for the clarification!

[Quin]

Hi Pelle,
Thanks for your improvements in V13 RC3, although I am sad to inform you that it didn't quite do what I wanted. It seems you did something slightly different from John Z, and now "ASCII Character Table" is reported as the column header for every row.
I also found two more typos:
Under the description heading for PoFMT's /s option, formatting is missing a T: "The /S option specifies the formating style." should be: "The /S option specifies the formatting style."
In the Pomake dependnencies documentation, the word "build" is written as "built". "The name of one or more targets, separated by spaces or tabs. The name can be a pseudotarget or a file to built." should be "The name of one or more targets, separated by spaces or tabs. The name can be a pseudotarget or a file to build."
Thanks!

EDIT:
It actually did improve a looot of the tables. For example, I had no idea that all the macros declared in something like <cpufeat.h> were supposed to be in a table; my screen reader simply didn't render them.
So Pelle, you actually did make a lot of improvements. Just the ASCII and ANSI tables, as well as any table with the same static text as its entire column row, are the only ones currently in need of fixing

[TimoVJL]

NVDA screen reader is free for downloading.
https://www.nvaccess.org/download/