I've posted a couple of Google Charts accessibility questions already; here's one more. Thank you in advance for your help.
Google Charts tables are surprisingly easy to make accessible to blind users, but I'm running into a perplexing problem. I'm making a website that uses standard Google category filters to produce a data table. I've added ARIA-live=polite and ARIA-atomic=true attributes to the table to signal screen readers to read out the entire table when it changes. This works perfectly most of the time; when a control is changed, after reading out the control behavior the screen readers will immediately start reading the new table.
Unfortunately, changes in class attributes trigger ARIA-live. For Google Charts tables also tagged with ARIA-atomic, this means that row hover behavior will trigger a reading of the entire table, because hovering over a row changes the row class. And if you move the mouse pointer over more than one row, it'll read out the entire table once for every row over which you pass.
EDIT: see NOTE below to clarify this paragraph. I've tried addressing this by tweaking the table's cssClassNames options, but the results are frankly maddening. Even when changing the tableRow and hoverTableRow options to the same class, the table will only apply that class when hovering, changing the class to " " when not hovering.
I've tried convincing my co-workers that users of screen readers won't be using mice, but I've been asked to find a solution anyway. Guh.
Does anyone understand how this row hover behavior works, exactly? Is the problem as inscrutable as I'm making it out to be, or am I missing something? Does anyone have any ideas for a workaround?
NOTE: Ryan B has a good workaround idea (see comment below), and that's exactly the kind of solution I'll propose if my co-workers insist that the current setup doesn't meet their standards. Thank you Ryan.
Still, in the hope that the problem is with my explanation, I'll clarify: when you hover over a row in a Google charts table, the background color changes. The Google Viz script manages this by listening for hover events over table rows. On hover, the script changes the row class name from something like "tr-goo-viz-table-row" to "tr-goo-viz-table-row-over", both of which are in the Google Viz CSS and only include styles of background colors (white and light grey, respectively).
In the HTML table call one can set the cssClassName option for hoverTableRow to "tr-goo-viz-table-row" (or set both tableRow and hoverTableRow to any class that only sets the background color) and visually, the hover behavior stops. But in an odd quirk, the script insists on differentiating the class names on hover even if you're telling it to keep the class names the same. Depending on the implementation the script will produce a doubled class name ("tr-goo-viz-table-row tr-goo-viz-table-row") for hover rows, or an empty class name ("") for non-hover rows, and either way that'll still trigger ARIA-live even though no style change is implemented and hovering has no visual effect.
Since I don't understand the implementation of this behavior, I'm hoping someone who understands it better than I do might know of a way to stop the hover-triggered class name changes altogether - killing the listener, etc. Something like adding "pointer-events:none" in the row CSS for example...except pointer-events wasn't supported in IE before IE11 and the people using this website will mostly be using IE9.
Related
Fullcalendar v4 - when I select a time range in timeGridWeek, the calendar changes appearance. The grid is visible, but the time bar and header disappear, leaving the only feedback as the small time display within the shaded selection range. Everything returns after I release the mouse/touch. Using jQuery 3.5.1 for some Bootstrap v4 elements.
Has anybody encountered this before?
Well, who have believed it? User error! In my css overrides I had given class 'fc-unselectable' a colo(u)r of '#fff' and this was causing not only the headers and time bar, but also any text not within a calendar event to 'disappear'. Naturally I would have tested the effects of this override at the time, so assume that some other change since then had brought about the unwanted behaviour. Now I am wracking my brain to find out why I felt that the white font was necessary in the first place. Must add more detailed comments to my code in future...
My site has these interactive tables that are inert until activated by an instructor when they are testing students. The backend is controlled by a vendor and I am the lowly web developer who cleans up their mess on the frontend so things look presentable. I've managed to change several tables indirectly through CSS and JS, but I can't apply anything to the HTML directly to the table since it's generated when the page loads. This particular table is perplexing,it will not shrink down to 720px. I tried everything from adddClass, nth-child, fixed sizes, etc. My last attempt was to write a function that set attributes to td's. It worked and it'll show on the developer tools but the actual table didn't shrink at all. I've been up 24+ hours so I might just be tired and not aware of simple mistakes. Anyways here's my demo. Thank you very much any help is very appreciated.
I just found this: Why is my table cell width wrong in Chrome?
Tables have a property called table-layout which is by default set to auto. It allows the table to be flexible and gives it the ability to distribute column widths on the fly. Setting my rogue table this way:
table-layout: fixed; width: 100%
made it behave and honor the widths I had assigned to it. Here's more details on table-layout
Demo
EDIT: I forgot to mention that this only happens in Chrome, but in Firefox and to a certain extent IE (it's a little off, but that's what you'd expect from a half-baked piece of work), are ok.
I am using the KendoUI html editor, in inline mode. It works fine, but I have found some problems with the arranging of toolbar items. Namely:
I have added custom tools to the toolbar. They are not correctly 'tagged' with the k-group-start, or k-group-end classes, and thus thir edges, and margins are not correct.
I can't influence where the toolbar puts in the 'k-group-break' item (what makes a linebreak on the toolbar).
I have tried to modify these in the selection changed event (according to the demo page, that gets fired every time I click into the edited area), but the kendo built-in logic overwrites my changes after that.
Has anyone encountered this problem? What could be a good solution? I am pretty lost, since I haven't found anything on this topic in the kendo documentation, so some hack might be needed.
Just add a tool ".Separator()" in your tools list and it will create an empty "li" ..
<li class="k-separator k-group-start"></li>
you can than style this element to create the spaces, I have made this li as a block element so it pushed everything which follows down.
Hope this helps.
Cheers
I've been using jsfiddle.net to try and prototype a scheduler where the items to be scheduled are dragged and dropped into it. I've gotten dragging and dropping from an "unassigned" list and onto the schedule table working. I've also gotten the ability to remove from the schedule table working. What I'm having a difficult time wrapping my head around is moving an item in the table to another part of the table.
The fiddle is located here. I'd appreciate any suggestions on getting internal drag and drop to work. I've been working on this all day and I'm starting to get blurry vision. Oh, and by all means if you think what I'm doing can be done better, please make the change, just let me know what version the fiddle is up to.
UPDATE
As per #SMathew and #darksky I've rebuilt the whole fiddle where I'm not directly shifting the table cells around, but instead their content.
I know you guys recommended using divs and/or spans, but I want to use the structure of the table, especially the rowspan to designate the height of the cell in 30 minute increments. It does work a lot better now, with the only bug being moving cells (or moreso their contents) around because I have to restore cells affected by the rowspan at the source site and remove the cells that will conflict with the rowspan at the target site.
The updated fiddle can be found here.
UPDATE 2 (FINAL)
So, I went back to the drawing board again, and after 64 fiddles, I finally got it to do what I want. In the end, the trick to get everything to work fine without manipulating the structure of the table. All I had to do was set cells that are in the way of a rowspan to display: hidden.
Anyway, for anyone whose interested, the new fiddle is here. I did discover that Chrome has some issues handling the API. I've noted them in the fiddle (along with a partial rant).
The problem is that you are trying to make the td elements draggable. When you remove/insert td elements from a table like that, you have to create a bunch of empty cells to balance it out. I would suggest keep the table intact and wrap draggable elements in a div or span tag. This way the table structure never changes. Your code will also be much simpler and efficient.
I'm prototyping a thin client UI using extjs and am looking for an effect that will simulate a form/pane flipping over to reveal another form/pane. Its for a details view for an object that has two major sets of properties.
I found a flex component that can do this, and can even simulate four different forms on the faces of a cube.
Just a sexier, more fun way of doing what you can already do with tabs.
This particular effect may not be available on a cross-browser basis quite yet. Doing perspective transforms on a given DOM element is only possible in two ways that I know of:
1) Renderer-specific extensions, like Webkit's -webkit-transform
2) Rendering the DOM element inside of a Canvas element and then doing transforms on that
The problem with #1 is that it's clearly not going to be cross-browser. The problem with #2 is that you'd more or less have to write your own complete markup renderer for canvas to really get everything in an arbitrary DOM element in there.
(OTOH, I wouldn't put it past some ambitious and clever JavaScript ninja to have attempted #2, so though I haven't seen it yet, I wouldn't be totally surprised if someone else can point towards something like it...)
I would stick with the tab solution if you want to get your project done within a reasonable time. This does not exist for ExtJS - the one in Flex does a 3D effect. The only solution close is to just have content in 4 cells of a table that slides into view (according to the direction of the arrow you used), within a DIV, and have the overflow property set to hide, so you can mask out the other cells and show one cell at a time. Then use the animation (fx) functions to slide the content in and out of view, perhaps with some arrows you hover over or click.