RFR: JDK-8186466: Fix accessibility and other minor issues in java.base
jonathan.gibbons at oracle.com
Mon Aug 21 22:31:52 UTC 2017
On 08/21/2017 09:38 AM, Jonathan Gibbons wrote:
> On 8/20/17 4:11 PM, Martin Buchholz wrote:
>> Again, I am happy to take the current state of this change.
>> On Sat, Aug 19, 2017 at 2:19 PM, Jonathan Gibbons
>> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>>
>> Actually, thead and tbody have no direct significance for
>> accessibility. They provide a semantic differentiation of the
>> content, and provide a hook for different styling, as you have
>> seen for "striped". Also note, although you can have many <tbody>,
>> you can only have at most one <thead>, and at most one <tfoot>.
>> Looking at Summary of BlockingDeque methods again, we have what might
>> logically be a thead in the middle of a table, and the law of "only
>> one thead, and only at the beginning" might be yet another hint that
>> the html gods want us to split this table. This could become a nested
>> table with two rows, one for "first" and one for "last", each of
>> which contains a subtable with a thead.
> I can investigate that.
It won't be a table with two rows; it'll be a table with 3 rows, because
it would need a header row with column headings :-( Also, you wouldn't
have the columns aligned, because of the use of two tables. And so you
might as well go with two separate tables, and the "First"/"Last" labels
moving into captions.
I guess I'd like to declare victory on the BlockingQueue/Deque tables.
They meet the desired accessibility requirements, which was the primary
goal. Even if they don't get the full "striped" approach, they are at
least visually similar to the original versions in the JDK 8 and JDK 9
API, with respect to font, centering, etc.
If we want to continue to enhance the appearance of these tables, we
should take it offline from this review, and do more experiments on
smaller API examples that are faster to turn around.
More information about the core-libs-dev