RFR: JDK-8186466: Fix accessibility and other minor issues in java.base
martinrb at google.com
Mon Aug 21 22:47:19 UTC 2017
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
More information about the core-libs-dev