- From: Alastair Campbell <acampbell@nomensa.com>
- Date: Tue, 3 Nov 2020 10:55:40 +0000
- To: Detlev Fischer <detlev.fischer@testkreis.de>, "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
- Message-ID: <DB8PR09MB333933109C58380CF15173AEB9110@DB8PR09MB3339.eurprd09.prod.outlook.com>
Detlev wrote: > Is there any reason not to turn the nested case into an extra exception though? If you add it as an exception you then have to build in the requirement as well, i.e. it is not an exception but a different scenario with a different requirement. Traditionally we’d build that separate scenario into the top section, but it would get very wordy and I was trying something… > (And what about the overlapping targets that Patrick mentioned? I think the current text would be a discouragement to overlapping targets (which is a good thing). In a case with complete overlap on one axis it would mean one link is smaller due to the overlap: [Two overlapping boxes, A on the left and B on the right. One red arrow spans the width of A, the other red arrow a smaller width from the right-side of A to the right-side of B.] In this case A is on top, therefore B is smaller on the X axis. With just a corner overlap it doesn’t make much difference to the calculation, but I think it still encouraging more spacing: [Two boxes where the bottom-right of A overlaps with the top-right of B. The measures are the same as though they are not overlapping.] Working these out gets harder when you overlap, but then that is something to be avoided from an accessibility point of view anyway… -Alastair
Attachments
- image/png attachment: image003.png
- image/png attachment: image005.png
Received on Tuesday, 3 November 2020 10:55:55 UTC