If a cell has the focus and the cell is for a column that is marked as non-editable or the editCellStarting returns false for any reason, the keyboard navigation no longer works and the user is "stranded" on that cell.
I have reproduced the issue in this example by clicking on the unit price column and then trying to tab forward or backward.
The key here is that rowEditing be turned off
It is a very common scenario for us to use editCellStarting to disable a specific cell in a row even though the column is turned off. Our users rely heavily on keyboard navigation, so this is a critical issue for us.
Hi Team,
We are trying to disable a particular cell based on the conditions and need the tab click navigate to the cell, that is next to disabled cell. We are trying the same as above but newCell.activate(event) is not working.
Could you please provide any samples available to achieve this.
Hello Lance,
Modern applications are evolving, their complexity increases dramatically and this introduced the need of new approach to keyboard navigation. We addressed this with the new user interface pattern called “Active element navigation”. This pattern reduces the number of tab stops, which is the reason behind the behavior that you are experiencing on your side. In general, less tab stops in a complex application means better usability and actually simplifies navigation, which has always been our top priority.
Of course, we understand that it is not easy to meet every requirement that our users might have and that sometimes complying with the previous tab behavior is necessary. That`s why we provided a way to implement keyboard navigation as per the specific needs of your application, which I believe was helpful in your scenario as well.
Thank you for choosing Infragistics for more than twenty years - this is a great honor for us! Thank you for taking time to share your feedback. I can assure you that we consider our customers opinion to be crucial for steering improvements at Infragistics and I will forward this to the mangers responsible for keyboard navigation.
Please let me know if I could be of any further assistance.
Thank you for the link to the blog.
Unfortunately, what it does illustrate is that users have to know that there are two different sets of keystrokes that they need to navigate depending on whether the cell is in edit mode or not: tab to get out of edit mode and move to the next cell or arrow if they are not in edit mode.
I understand the specification you are attempting to follow, but I simply cannot understand how this improves the actual usability of the grid.
Most users that I know don't care about keyboard navigation to the various other grid elements, they simply care about moving to the next cell since they are entering a lot of data in these grids and it needs to be as efficient as possible.
Their efficiency will decrease and their frustration with the product will increase if they are in edit mode and have to use keys on different sides of the keyboard depending on the mode the grid happens to be in.
While I can appreciate that there are specifications that are published, many of the specification writers do not take into account real-world usage like excel-style editing. I think that the current design of the grid is incredibly inconsistent and make in fact cause us to look elsewhere for a solution. Which would be a real shame since we have been loyal Infragistics customers for well over 20 years.
I understand you concerns regarding the Tab behavior. Having in mind that our customer`s requirements may vary, the new keyboard navigation is designed to be highly customizable. As it is in your scenario, developers are given the ability to adjust the behavior as per their specific needs, with a reasonable amount of code, and yet we keep our product compliant to the world standards regarding aria, described in W3C`s WAI-ARIA Authoring Practices.
I believe our “Improving Usability, Accessibility and ARIA Compliance with Grid Keyboard Navigation” blog post will shed some light on our new user interface pattern for keyboard navigation.
Please let me know if you have any additional concerns or questions.
Thank you again for the response. Unfortunately, users don't really know or care about specifications, they care about getting their job done as efficiently as possible.
The suggestion that using arrows to navigate isn't practical at all and requires the user to use two different navigation mechanisms depending on the element that currently has focus.
For example, if I am editing a date field and press the right arrow, the cursor simply goes to the end of the date, not to the next cell. However, tab does go to the next cell.
Based on this behavior, either the writers of the specification have never actually used a component like a grid or the Infragistics implementation does not meet the implementation.
I have been working with Infragistics and other vendor grids for more than 20 years, and this is the first time that I have had this explanation given for this type of behavior.