[Feature Request] EvTable Enhanced Screenreader Support

[jaborsh]

Describe the solution you'd like

Currently, EvTable formats its rows/columns in such a way that is unfriendly for screenreaders.

In this image, the Description portion of the row wraps into multiple lines. While this is perfect for visual users, it is less-so for those using screenreaders, as the second line will be read AFTER the status report. We should implement a method to negate this multi-line wrapping for screenreader users. The crop method in EvCell is a sub-optimal workaround for the time being as the entirety of the text will not display.

[InspectorCaracal]

While I don't have anything against the suggestion, I think it would likely be simpler to do a check on the user's protocol in your code and simply not use an EvTable for those with the screenreader flag. The entire functional purpose of EvTable is visual formatting: if you don't need the visual formatting, you don't need the table.

[chiizujin]

I don't really know much about the requirements of a screen reader but if you did want something to "unwrap" the table you could pass it through the function below and send the returned string to the client instead of sending the table. Though, as InspectorCaracal says, this would be doing the work then undoing it again instead of just bypassing the EvTable:

def un_evtable(table, row_numbers=False):
    string = ""
    for i in range(table.nrows):
        row = [col[i] for col in table.worktable]
        if row_numbers:
            string += f"Row {i + 1}\n"
        for cell in row:
            cell_string = " ".join([data.clean() for data in cell.data])
            if cell_string:
                string += cell_string + "\n"
    return string.rstrip()

This creates a string with one line per cell, in row order.

[Griatch]

In principle, the EvTable's output could implement something like the solution @chiizujin has here, just swapping to it when in screenreader mode. Kinda cumbersome to add that across all commands though.

[jaborsh]

Marked as not planned given the alternative solution of handling directly instead of creating a method to essentially invalidate the entire point of EvTable to begin with.