We want to use the embedded timeline to provide Twitter widgets on our sites but we currently can't because the embedded timeline have WCAG 2.0 AA failures and our sites are legally obligated to meet WCAG 2.0 AA (as are the sites of many other jurisdictions). The oAuth approach can be used in some cases but there still remain many cases where oAuth is not possible without exposing the credentials in JavaScript (since server-side approaches are not always possible).
We would fix these WCAG 2.0 failures ourselves if we could but the way the embedded timeline is implemented makes this impossible because the it uses an iframe and provides insufficient configuration options to address the problem. Here are the WCAG 2.0 AA failures that are preventing us from using the embedded timeline:
1) Insufficient contrast in the light theme for the Twitter handle, date, Show summary, Expand and Tweet button. In the light theme it is #999999 foreground and #FFFFFF background which is only a 2.8:1 contrast ratio when the minimum required by WCAG 2.0 Success Criterion 1.4.3 is 4.5:1 (http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html). The following are the possible solutions:
a) Give control over this foreground colour like is done with the regular links. So support for another data-* attribute would work.
b) Change the colour from #999999 to #707070 or darker for the light theme. That would increase the contrast ratio to at least 5:1.
c) Don't use an iframe so the appearance can be overridden on the client side.
Note that setting the background to transparent doesn't help as there is no background colour that will ensure sufficient contrast for all text without changing the text colour first
2) Insufficient contrast in the dark theme for the Twitter handle, date, Show summary, Expand and Tweet button. In the dark theme it is #999999 foreground and #333333 background which is only a 4.4:1 contrast ratio when the minimum required by WCAG 2.0 Success Criterion 1.4.3 is 4.5:1 (http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html). The following are the possible solutions:
a) Give control over this foreground colour like is done with the regular links. So support for another data-* attribute would work.
b) Change the colour from #999999 to #A0A0A0A or lighter for the dark theme. That would increase the contrast ratio to at least 4.8:1.
c) Don't use an iframe so the appearance can be overridden on the client side.
Note that setting the background to transparent doesn't help as there is no background colour that will ensure sufficient contrast for all text without changing the text colour first.
3) The Reply, Retweet and Favorite buttons can't be reached or activated with a keyboard or on a touchscreen. They seem to be hidden by default (with visibility: hidden) and only show up on a mouse hover (cannot tab to these buttons while they are hidden). This fails WCAG 2.0 Success Criterion 2.1.1 (http://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation-keyboard-operable.html). The following are the possible solutions:
a) Give control over the visibility of these buttons so we can make them always visible. So support for another data-* attribute would work.
b) Make these buttons always visible (so remove visibility: hidden).
c) Provide a button to reveal the other buttons (not ideal but at least the buttons are available for keyboard and touchscreen).
d) Don't use an iframe so the visibility can be overridden on the client side.
Please fix these WCAG 2.0 issues as quickly as possible as the May 7 date is fast approaching and we do not have a workable solution for replacing the existing API v1.0 Twitter widgets on our sites.