{"issue":{"state":"open","pull_request":{"diff_url":null,"html_url":null,"patch_url":null},"milestone":null,"user":{"avatar_url":"https://secure.gravatar.com/avatar/6be8e584a0f454ac2dc7600bdeaca7b7?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"6be8e584a0f454ac2dc7600bdeaca7b7","url":"https://api.github.com/users/brendo","login":"brendo","id":69268},"assignee":null,"updated_at":"2011-11-16T13:11:14Z","labels":[],"closed_at":null,"comments":2,"url":"https://api.github.com/repos/symphonycms/symphony-2/issues/901","body":"While not a high priority, we definitely should be aware of the [ATAG 2.0 guidelines](http://www.w3.org/TR/ATAG20/) and ensure that Symphony does it's best to adhere to them wherever possible. I'm not sure of the current state of Symphony against such guidelines (I imagine we are doing better than most), but it'd be worthwhile reviewing.\r\n\r\nAs a side note, here in a Australia it will be required that all government websites adhere to WCAG 2.0 standards by the end of 2012 (Level A (Single A) by 31 December 2012, Level AA (Double A) by 31 December 2014) and we have noticed in a lot of tenders the requirement for authoring tools to comply with this as well.","html_url":"https://github.com/symphonycms/symphony-2/issues/901","title":"Review ATAG2.0 guidelines","number":901,"id":2252837,"created_at":"2011-11-16T04:21:39Z"},"action":"created","comment":{"user":{"avatar_url":"https://secure.gravatar.com/avatar/6be8e584a0f454ac2dc7600bdeaca7b7?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"6be8e584a0f454ac2dc7600bdeaca7b7","url":"https://api.github.com/users/brendo","login":"brendo","id":69268},"updated_at":"2011-11-16T13:11:14Z","url":"https://api.github.com/repos/symphonycms/symphony-2/issues/comments/2759192","body":"I think they are very much related, one of the principles of ATAG is for the app to support WCAG, so it's almost two birds with one stone. \r\n\r\nATAG focuses on two principles:\r\n\r\n1. Making the authoring tool interface accessible\r\n2. Support the production of accessible content\r\n\r\nThe first is the core's job (to a degree), the second is more a of global push through all extensions I feel. One of the more interesting things I noticed while skimming the document was the reference of attempting to adhere to [platform accessibility guidelines](http://www.w3.org/TR/2011/WD-IMPLEMENTING-ATAG20-20110721/#gl_a12), which is interesting and perhaps relevant considering the UI work occurring now?\r\n\r\nWhile we are talking about accessibility, we should look at using [WAI ARIA](http://www.w3.org/WAI/intro/aria) as well, which from what I know (limited knowledge at this stage) can help screenreaders understand the page semantics more by the use of various `role` attributes.\r\n\r\nAll very interesting stuff, even if it's relatively behind the scenes and a usual user wouldn't know the difference.","id":2759192,"created_at":"2011-11-16T13:11:14Z"}}