- From: Alastair Campbell <acampbell@nomensa.com>
- Date: Thu, 28 Jun 2018 23:14:10 +0000
- To: Wayne Dick <wayneedick@gmail.com>, public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>
- Message-ID: <AM5PR0902MB20021620EDAA9D7C46BFB81CB94F0@AM5PR0902MB2002.eurprd09.prod.outlook.>
Hi Wayne, I think it is reasonably straightforward, the WAI site works well with zoom / reflow at 320px, but when text-spacing is added it over-flows the window-width due to the menu. Laura pointed to issue 850, where we got to the point of no-one disagreeing with my proposed response. I just updated it now: https://github.com/w3c/wcag21/issues/850#issuecomment-401199622 So we can bring that to a group resolution soon. That basically said that SC are not cumulative, however, where there are variations of a page, each SC should be tested in each variation. (As-per the new conformance note.) That seems like a good balance, as otherwise in a responsive design which flexes (in a good way), you have a huge burden of testing at every possible width of page. Using breakpoints as ‘variations’ seems reasonable. The interesting aspect here is at what point the ‘variation’ changes. From the CSS It looks like there are variations at 0-35em, 47.5em, and 60em. (560px, 760px, 906px). So (my interpretation of) the conformance requirement is that if text-spacing works at under 560px, that passes, as that is a variation of the page. However, in the case of the WAI site I’m sure Eric (and the team) would want to address this. Most of the content is fine, it is just that the menu in the header gets pushed out which causes layout issues further down as well. Would you like to raise a bug? https://github.com/w3c/wai-website/issues Cheers, -Alastair From: Wayne Dick <wayneedick@gmail.com> Sent: 28 June 2018 20:14 To: public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org> Subject: Problem with WAI Site Dear Group, I would like to keep this within LVTF until we resolve the problem. I think there is a very subtle technique here. The WAI site fails at 320 CSS px. It over flows the pate. Her is how it works. The page works with no adjustment to letter-spacing, but with 0.12em letter spacing at 320 CSS px it fails. The experiment was conducted as follows. I used a user stylesheet on Chrome, Firefox and Safari. * {letter-spacing: 0.12em !important}. I used Stylish for Chrome and Firefox and the preferences > advanced > stylesheet option for Safari. I tried Edge as well but it failed for other reasons, so I've left it out. Here is how I produced 320 CSS px (341 CSS px for Safari). Chrome allows enlargement up to 500%. So on my iMac with 1600x900 this gives 320 CSS px. The site fails. Safari only gives 300% enlargement. When I lower the resolution 1024x768 I get 341 CSS px. The site failed. (I used my Macbook Air for this last test. the iMac is hard to set resolution smaller than 1600x900.) Firefox gives up to 300% enlargement standard, but you can change this in the About:Config file. I set the last 3 enlargement values to 300%, 400%, 500%. With these settings I applied 500% to my iMac at 1600x900 giving 320 CSS px. The page failed. All three browsers failed at anything smaller than 341 CSS px. The 320 cases were worse. The only deficient browser was Edge. It just failed to split two column regions 300% with 1280 width. The main finding is this. When the WAI site is given 341CSS px or less, it fails when letter-spacing is 0.12em. The same browsers perform well on other sites. Alastair stated worry on this issue during our discussions. So, I think this problem is significant. Eric is a good programmer. That means the issue must be subtle. When we do, it will be a technique. I want to emphasize that Eric has worked hard on this site; he is an excellent developer, and he couldn't anticipate this issue. I don't want this to go on the general list until we have a reason why the failure occurred. It would be unfair to Eric. Best to All, Wayne
Received on Thursday, 28 June 2018 23:14:40 UTC