- From: Fred Esch <fesch@us.ibm.com>
- Date: Thu, 9 Jun 2016 08:58:12 -0400
- To: "ext Janina Sajka" <janina@rednote.net>
- Cc: "Accessible Platform Architectures Working Group" <public-apa@w3.org>
- Message-Id: <OFE9CB7030.3203FACD-ON85257FCD.004405CA-85257FCD.00473F51@notes.na.collabserv.c>
Hi Janina, CSS Psuedo-Elements Module Level 4 has accessibility issues that we want to keep track of and work with the CSS WG on. Please put action-2059 on the agenda. Highlight pseudo elements present accessibility issues. ::spelling-error and ::grammar-error may show visible highlighting but will the triggering (grammar error/spelling error) be passed on to AT? The text in Section 3.6 Security and Privacy Considerations suggests not. Because the styling of spelling and grammar errors can leak information about the contents of a user’s dictionary (which can include the user’s name and even includes the contents of his/her address book!) UAs that implement ::spelling-error and ::grammar-error must prevent pages from being able to read the styling of such highlighted segments. Since highlight pseudo elements use only visual changes they may present issues for low vision and color blind users. I think at a minimum a note should be added letting readers know that some forms of highlighting won't be perceived by all users. UA handling of ::before, ::after, ::placeholder pseudo elements are candidates for a CSS AAM. Section 6 Additions to the CSS Object Model (first sentence) states Pseudo-elements should be reachable by script, stylable from script, and available as event targets. I am wondering whether statements like this will affect how ARIA docs define things that must be included in the accessibility tree? For instance potentially being a source of an event usually triggers inclusion in the accessibility tree. Regards, Fred Esch Watson, IBM, W3C Accessibility IBM Watson Watson Release Management and Quality
Attachments
- image/gif attachment: 08937712.gif
Received on Thursday, 9 June 2016 13:00:46 UTC