RFR: JDK-8186466: Fix accessibility and other minor issues in java.base

[Martin Buchholz]

I'm happy.  Thanks for going the extra kilometer.

On Mon, Aug 21, 2017 at 3:31 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

>
>
> 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>> wrote:
>>>
>>>     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.
>>
>
> I investigated.
>
> 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.
>
> -- Jon
>
>