You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are some accessibility issues with the way we structure date/time values. We seem to be using a consistent format (the <time> element) in two distinct contexts, which have slightly different ramifications for screenreaders.
I don't have specific suggestions for improvement for these because I'm not certain I understand why we are using the time element and some of its attributes (I'm not suggesting it isn't a good idea to use it, just that I don't think I understand the implications).
Stream updated value
On the provider home page we display the "stream metadata" box with counts of files and records in the stream, etc.
At the top we show a value like "about 22 hours ago". This is coded like this:
The works fine visually, but when using a screenreader you hear the all of time element attributes read aloud, including the "%B #e %Y", etc. Then you hear the "May 31, 2022" time value and finally the "about 22 hours ago" span value that is visible in the UI. This is because the time element is inside of a title attribute, I assume. In this case I wonder what benefit we get from putting the time element there?
Uploaded/Date created dates in tables
In table columns like Date created or Last upload throughout the applications we use a structure like this:
When read by a screenreader we hear the date value twice. However, when that exact same element is wrapped in a link, we only hear the date value once.
For example, in the Activity page Uploads tab table the Last upload column displays the time element within a link, while the Last successful upload does not. When this table is read by a screenreader, you hear the Last upload column (A in the screenshot below) read correctly (date read once) while the Last successful upload value (B) is read twice, even though in many cases the underlying source code for the element is exactly the same (i.e., when the last upload was a successful upload).
Therefore, because most of the dates we display in other parts of the application are not wrapped in a link, most often when using a screenreader you will hear each date value in a table cell repeated twice.
The text was updated successfully, but these errors were encountered:
There are likely a lot of interactions going on with the local-time gem here, which outputs the <time> element, so that will be a good place to start when investigating.
There are some accessibility issues with the way we structure date/time values. We seem to be using a consistent format (the
<time>
element) in two distinct contexts, which have slightly different ramifications for screenreaders.I don't have specific suggestions for improvement for these because I'm not certain I understand why we are using the time element and some of its attributes (I'm not suggesting it isn't a good idea to use it, just that I don't think I understand the implications).
Stream updated value
On the provider home page we display the "stream metadata" box with counts of files and records in the stream, etc.
At the top we show a value like "about 22 hours ago". This is coded like this:
The works fine visually, but when using a screenreader you hear the all of time element attributes read aloud, including the "%B #e %Y", etc. Then you hear the "May 31, 2022" time value and finally the "about 22 hours ago" span value that is visible in the UI. This is because the time element is inside of a title attribute, I assume. In this case I wonder what benefit we get from putting the time element there?
Uploaded/Date created dates in tables
In table columns like Date created or Last upload throughout the applications we use a structure like this:
When read by a screenreader we hear the date value twice. However, when that exact same element is wrapped in a link, we only hear the date value once.
For example, in the Activity page Uploads tab table the Last upload column displays the time element within a link, while the Last successful upload does not. When this table is read by a screenreader, you hear the Last upload column (A in the screenshot below) read correctly (date read once) while the Last successful upload value (B) is read twice, even though in many cases the underlying source code for the element is exactly the same (i.e., when the last upload was a successful upload).
Therefore, because most of the dates we display in other parts of the application are not wrapped in a link, most often when using a screenreader you will hear each date value in a table cell repeated twice.
The text was updated successfully, but these errors were encountered: