aria-colspan(property)

As you may be aware of, making the simple tables accessible is much easier than making the complex tables accessible. In my view, there is no problem with the complex tables as long as they are accessible to the assistive technology users. Usually, complex tables would have multi-level column headers/row headers and it is one type of variety but there are many more verities within this complex tables. We are not going to discuss all the varieties of the complex table rather will discuss the multi-level column headers in this post. Let us understand what is multi-level column headers all about. Usually, we see the pattern like one single column header for all the data cells that are present in that particular column and basically it is called as simple data table. In case of complex table with multi-level column headers, each data cell with respect to the that particular column may have more than one single column header. To put it simpler, a column header would have sub column headers in the complex table with multi-level column headers. To understand which is main column header and which is sub column header visually, authors need to group the related column headers technically(like all the sub column headers need to be grouped with the corresponding main column header by merging the cells with the help of CSS paddings and HTML col span techniques. When they do so, it is semantical to both sighted and assistive technology users that how many cells are spanned or so. Since the context that I have made so far is all about native data table, the semantical information is conveyed to the assistive technology users. However, the information about how many columns are spanned would not be conveyed to the assistive technology users if it is custom table as custom table is built with <div> and <span> tags and with other CSS properties and it is a problem.

In order to address this problem, aria1.1 introduced new brand attribute and it is aria-colspan. Aria-colspan defines the number of columns spanned by a cell or gridcell. When aria-colspan is defined for the cells in the custom table, assistive technologies like screen reader are expected to understand how many columns are spanned and are expected to convey the same information to the users. The information about how many columns are spanned in the table enables the screen reader users to visualize the table structure very clearly than ever before. as I have explained this concept with the spanning of column headers, it does not mean that spanning the columns is not limited to column headers. Author can span any columns by using aria-colspan attribute based on the requirement.

 

 

Author notes

 

  • Author must use this attribute on the below roles only
    • Cell
    • Gridcell
    • Column header
    • Row header
  • Authors MUST set the value of aria-colspan to an integer
    • greater than or equal to 1
    • less than value that prevents overlapping of other cells in the same row. In simple terms, if author wants to span 3 columns then the value of aria-colspan must be set to 3 only but not to 4 or 5 or so.

 

Notes for assistive technology venders

  • Assistive technologies should not expose the value of aria-colspan for an element if equivalent host language attribute is provided rather assistive technologies should expose the value of the host language’s attribute.

 

 

 

Sample code snippet

if given

<div role=”table”>

<div role=”row”>

<div id=”sd” role=”cell” aria-colspan=”2″>country</div>

</div>

</div>

then expose aria-colspan=”2″ on the element with id=”sd”

 

References

 

Menu, menubar, , and menuitem roles

Since the modern websites are rich in the look wise, it is important to provide the same rich experience to the assistive technology users too. Unfortunately, there are no HTML semantics for the few of the rich controls such as menu, menubar, tab, tree and so on..  usually, authors bring such rich visual look by using CSS design patterns. Let me talk more on menus and menubar in this post. Since there are no HtML semantics for menus and menubar, authors may have to use CSS for the either anchor element or custom container to get the visual appearance of the menu or menubar. When they do so then control might be visually appearing as menu or menubar but assistive technologies do not interpret the same. When assistive technologies do not interpret the way how sighted person perceives the control then it is high chance that assistive technology users would not be aware of the complete functionality of the control. For example, if menu is announced as link by screen reader then it is not the identical experience to the screen reader users. in addition, menu and link might not have the same functionality. In order to provide the semantics for such rich controls, aria introduced menu, menubar, and menuitem roles.

 

Menu role

When we go to restaurant then what is the first thing that we look for. Obviously, we look for the menu. What does it contain? Usually, menu contains the list of the choices that we need to have for the food. On the similar lines, aria menu role is nothing but A type of widget that offers a list of choices to the user. A menu is often a list of common actions or functions that the user can invoke. One thing that we need to remember here is that those list of the options are displayed only when user invokes the menu widget but those list of the options are not visible by default.

The menu role(role=”menu”) is appropriate when a list of menu items is presented in a manner similar to a menu on a desktop application. In aria1.1, aria-orientation=”vertical”  has been added as The default implicit value for menu role. The child or required own elements for menu role are menuitem, menuitemcheckbox, menuitemradio.

Menubar role

Menubar role is also kind of the similar concept as menu role. When the list of the choices/options are visually persistent then it is called as menubar. In a simple words, the list of choices are always visible on the screen by default then that complete bar is called as menubar. Most of the people would think that menu is the child of menubar but it is not true. Even though, The menu and menubar are at the same level from the hierarchy wise but they are different in nature. Let me tell you the difference clearly. The list of the choices are displayed when user invokes menu widget for the menu whereas the list of the choices are always visible on the screen by default for the menubar. That is difference between both of them. The child or required own elements roles for the menu and menubar are same and they are menuitem, menuitemcheckbox, menuitemradio.

The menubar role(role=”menubar”) is used to create a menu bar similar to those found in Windows, Mac, and Gnome desktop applications. A menu bar is used to create a consistent set of frequently used commands. Authors should ensure that menubar interaction is similar to the typical menu bar interaction in a desktop graphical user interface. In aria1.1, aria-orientation=”horizontal”  has been added as The default implicit value for menubar role and Menubar is usually presented horizontally.

Menuitem role

Menuitem is nothing but An option in a set of choices contained by a menu or menubar. A Menuitem(role=”menuitem”)  may or may not contain sub menu. If the menu item has its aria-haspopup attribute set to true, it indicates that the menu item may be used to launch a sub-level menu, and authors SHOULD display a new sub-level menu when the menu item is activated. Authors MUST ensure that menu items are owned by an element with role menu or menubar in order to identify that they are related widgets. Authors MAY disable a menu item with the aria-disabled attribute.

Sample code snippet

<ul role=”menubar” id=”appmenu”>

<li role=”menuitem” aria-haspopup=”true”>

Edit

<ul role=”menu”>

<li role=”menuitem”>Undo</li>

<li role=”menuitem”>Redo</li>

<li role=”separator”></li>

<li role=”menuitem”>Cut</li>

<li role=”menuitem”>Copy</li>

<li role=”menuitem”>Paste</li>

</ul>

</li>

</ul>

 

References

 

aria-colindex(property)

Overview

 

As discussed in aria-colcount(property) post, at time, author might not want to show all the total columns of the table in the DOM due to the usage of advance filters and so on rather author might want to show only portion of the columns in the DOM. When author wants to show only the portion of the columns of the table in the DOM then it is  suggested to use aria-colcount property to communicate the total no of columns to the assistive technology users. Up to this, we are clear with the concept. However, using aria-colcount alone would not be sufficient to convey all the table properties to the assistive technology users. Since only the portion of the columns are visible in the DOM, assistive technologies like screen readers do not understand which cell/column has the data. As a result, screen readers might end up with incorrect column index announcements when user navigates through the table and it is a problem.

In order to address this problem, aria1.1 introduced the new brand table property and that is aria-colindex. When aria-colindex property is set on the cell container of the table then screen readers would understand column index of that cell and announces the column index accordingly. Let me elaborate this little bit more. As have been discussing, this property should be used only the portion of the columns of the tables are available in the DOM. By considering this important point in the mind, let us think there are 4 columns(column2, column3, colunm5, and column9) of the table are available in the DOM out of 16 total columns. If aria-colindex is set as 2 for the column2 cell then screen readers would announce the column2 and this announcement is appropriate. Failing to set this attribute may result the incorrect column index announcements by screen reader software and this intern confuses the users a lot. When aria-colcount is set for the complete table container then it is necessary to set the aria-colindex to define the position of the visible column of that table.

In a broader view, aria-colindex Defines an element’s column index or position with respect to the total number of columns within a table, grid, or treegrid.

 

Author notes

  • Authors should use this property for the below roles only<
    • Cell
    • Row
    • Column header
    • Gridcell
    • Rowheader
  • Authors should not set/define this attribute If all of the columns are present in the DOM as user agent can automatically calculate the column index of each cell or gridcell
  • Authors should set/define this attribute only when portion of the columns is present in the DOM at a given moment,
  • this attribute is needed to provide an explicit indication of the column of each cell or gridcell with respect to the full table
  • Authors MUST set the value for aria-colindex to an integer greater than or equal to 1,
  • Aria-colindex must be greater than the aria-colindex value of any previous elements within the same row,
  • Aria-colindex must be less than or equal to the number of columns in the full table
  • aria-colindex cannot be greater than aria-colcount, unless aria-colcount is unknown (e.g. value -1)
  • aria-colindex must be set on the start of the span if the cell or gridcell spans multiple columns or multiple rows
  • If the set of columns which is present in the DOM is contiguous, and if there are no cells which span more than one row or column in that set,<
    • aria-colindex is not needed to set on the every cell
    • aria-colindex can be set on the row element with a value equal to the the index number of the first column in the set. Browsers will then compute a column number for each cell in the row.
  • aria-colindex needs to be set on each cell in the row If the set of columns which is present in the DOM is noncontiguous

 

Sample code snippet

if given

<div role=”table”>

<div role=”row”>

<div id=”SD” role=”cell” aria-colindex=”4″ aria-colcount=”8″>suman damera</div>

</div>

</div>

then expose aria-colindex=”4″ on the element with id=”SD”

 

References

 

 

 

aria-modal(property)

First of all, Let us understand What is a modal. Modal is something that interrupts your current work flow on your main page and usually, user navigation is limited within the modal element itself. In other words, users cannot access the background content when modal is displayed. Even though visually the background content is inert/grade out, it is high chance that screen reader users can access the background content, which is a problem.

To address this problem, what we have been doing is that we use aria-hidden=”true” attribute to hide the background content from the screen reader users. When modal is closed, we flip the aria-hidden value from true to false, so that screen reader users can access the content when they are returned to the actual web page. These are the techniques that we have been following to hide/unhide the background content from the screen reader users.

Aria 1.1 introduced the aria-modal attribute to hide the background content directly instead of using aria-hidden attribute. Authors should use aria-modal attribute in conjunction with dialog/alertdialog role. When aria-modal is set to true in the dialog/alertdialog container then the expectation is that:

  1. Assistive technologies do not expose the background content
  2. User navigation is limited to the modal elements itself
  3. Assistive technology should place the focus on the modal element when it is displayed unless the focus has explicitly been placed else where

all these things are being taken care automatically when aria-modal=”true” is used. Imagine’, how cool it is. Hence,  we don’t need to use aria-hidden attribute any more.

Author notes

  • Author should use aria-modal attribute in conjunction with dialog/alertdialog role.
  • When a modal element is displayed, authors MUST ensure the interface can be controlled using only descendants of the modal element. In other words, if a modal dialog has a close button, the button should be a descendant of the dialog.

Sample code snippet

if given

<body>

<h1 id=”Test2″>Modal Dialog Box Test</h1>

<div role=”dialog” aria-modal=”true” id=”test”>

<input type=”button” value=”ok”/>

</div>

</body>

then the element with role=”dialog” and id=”test” exposes aria-modal=”true”

 

 

References

 

 

Cell Role

When It is not possible to construct the tabular content by using HTML <table> tag for any reason then they are called as custom tables. On the similar lines, when we cannot use the HTML <table> tag then it is obvious that descendants of the HTML table cannot be used. When I say descendants then what does it mean with respect to the HTML <table> tag. The descendants of HTML <table> tag could be <td>, <th> <tr>, <tbody>, <tfooter>, <thead> and so on.. in other words, authors cannot use all the mentioned descendants unless HTML <table> tag is being used to construct the tabular content. Each descendant conveys some or other semantical information to the assistive technology users. Let me talk more about <t> descendant. <td> tag conveys the semantical information to the assistive technology users that it is a cell. Unfortunately, custom tables are constructed with <div> and <span> tags. Divs and spans do not convey the any semantical information to the assistive technology users and this is a problem.

In order to address this problem, aria 1.1 introduced table and cell roles. To provide the semantics to the custom table, author must provide Table role to the entire container. Similarly, to provide the cell semantics in the custom table, author must provide cell role. Cell role is related to gridcell and It is equivalent of HTML <td>. All the context that I made about the tables is related to the static tables but not related to interactive tables. To be very clear and precise, cell role must be used only for static tables that are having table role.

 

Author notes

 

  • Authors MUST ensure elements with role cell are contained in, or owned by, an element with the role row.

 

Code snippet

<div id=”foo” role=”table” aria-colcount=”8″>

<div role=”row”>

<span id=”test” role=”cell” aria-colindex=”4″ >test cell</span>

</div>

</div>

References

 

 

 

aria-errormessage property

We have aria-describedby attribute in the aria 1.0. what we as authors have been doing is that we associate instructions as well as inline error message of the form control by using aria-describedby attribute. Let us understand what does an inline error message mean.

imagine there is a form on the page. Form has first name, last name, and submit controls. When submit button is invoked without providing any input in the both fields then it displays inline error messages. For the first name form field, it displays the “please enter first name” as inline error message. For the last name form field, it displays the “please enter last name” as inline error message. We have been associating these type of inline error messages by using aria-describedby attribute so far.

Aria 1.1 introduced aria-errormessage attribute to associate these type of inline error messages with the form fields. It claims that it is more semantic method to associate the error messages by using aria-errormessage instead of using aria-describedby attributes. The aria-errormessage attribute references another element that contains custom error message text.

Author notes

  • Authors can use this attribute on all the elements of base markup
  • author should use aria-invalid attribute in conjunction with aria-errormessage.
  • aria-errormessage should not be applicable if the object is in the valid state and either has aria-invalid set to false or no aria-invalid attribute
  • Author should ensure that error message is visible on the screen when it is displayed.
  • Authors MAY use live regions for the error message element applying either an aria-live property or using one of the live region roles, for example, alert.

 

Sample code snippet

<!– Initial valid state –>

<label for=”startTime”> Please enter a start time for the meeting: </label>

<input id=”startTime” type=”text” aria-errormessage=”msgID” value=”” aria-invalid=”false”>

<span id=”msgID” aria-live=”off” style=”visibility:hidden”> Invalid time:  the time must be between 9:00 AM and 5:00 PM” </span>

 

<!– User has input an invalid value –>

<label for=”startTime”> Please enter a start time for the meeting: </label>

<input id=”startTime” type=”text” aria-errormessage=”msgID” aria-invalid=”true” value=”11:30 PM” >

<span id=”msgID” aria-live=”assertive” style=”visibility:visible”> Invalid time:  the time must be between 9:00 AM and 5:00 PM” </span>

References

 

Searchbox role

Did you see any website without search form field? Almost every website usually has this search form field. The purpose of having this search form field on the website is to search as per user need and navigate to the respective sections quickly  instead of browsing the entire website. Imagine, this search form field is not constructed with html input type search and is constructed with the custom controls then this search form control might not be accessible to assistive technology users. if this search form control cannot be constructed with html input type search for some reason then we are left with the option of using new aria1.1 searchbox role to make this custom control accessible.

Aria1.1 Searchbox role can be used for the type of textbox intended for specifying search criteria . When searchbox role is applied to container then screen readers are expected to announce as “search edit type and text” or something like that. Search role and searchbox role are different from each other and they are not identical/same. To be precise, The role=”searchbox” must be provided for focusable element whereas role=”search” is the landmark that includes focusable active elements. On the similar lines, textbox role and searchbox role are different from each other and they are not same/identical. Searchbox role is equivalent of the html <input type=”search” element.

Author notes

  • Author must set the accessible name when searchbox role is used

 

 

Code snippet

 

<div id=’test’ role=’searchbox’ contenteditable=’true’></div>

 

References

 

aria-haspopup(property)

aria-haspopup attribute was present in the aria1.0 as well but few modifications have been made to this attribute in aria1.1. Before we get into that, Let us understand what is popup content as per the specification. Popup content usually appears as a block of content that is on top of other content. It could be menu, dialog, and so on..

In aria 1.0, aria-haspopup values are limited to only true/false. But in aria 1.1, aria-haspopup has list of token values and it is enumerated type. The token values are:

  • Aria-haspopup=”false”, indicates the element does not have any popup
  • Aria-haspopup=”true”, indicates that popup is menu
  • Aria-haspopup=”menu”, indicates that popup is menu
  • Aria-haspopup=”dialog”, indicates that popup is dialog
  • Aria-haspopup=”grid”, indicates that popup is grid
  • Aria-haspopup=”listbox”, indicates that popup is listbox
  • Aria-haspopup=”tree”, indicates that popup is tree

Aria-haspopup=”true” and aria-haspopup=”menu” are one and the same and aria-popup=”true” is for to support the backward compatibility.

Notes for assistive technology vendors

  • Any other value apart from the above mentioned token values should be treated as aria-haspopup=”false”, by assistive technologies which means that element does not have popup.

Author notes

  • Author should use Aria-haspopup attribute only for keyboard focusable elements.
  • Author should not set this attribute for the element that opens tooltip as popup and tooltip are not one and the same.

Sample Code Snippets

button haspopup unspecified

if given

<div id=”test” role=”button”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role but not expected to expose aria-haspopup

button haspopup true

Note: as discussed earlier, the ARIA spec says “To provide backward compatibility with ARIA 1.0 content, user agents must treat an aria-haspopup value of true as equivalent to a value of menu.”

if given

<div role=”button” aria-haspopup=”true” id=”test”>

OK

</div>

then for the element of id test, assistive technologies are expected to  expose the button role and aria-haspopup=”menu”

button haspopup false

if given

<div id=”test” role=”button” aria-haspopup=”false”>

OK

</div>

then for the element of id test, assistive technologies  are expected to expose the button role but are not expected to expose aria-haspopup

button haspopup dialog

if given

<div id=”test” role=”button” aria-haspopup=”dialog”>

OK

</div>

 

then for the element of id test, assistive technologies are expected to expose the button role along with the presence of the dialog.

button haspopup grid

if given

<div id=”test” role=”button” aria-haspopup=”grid”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role along with the presence of grid.

button haspopup listbox

if given

<div id=”test” role=”button” aria-haspopup=”listbox”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role along with the presence of listbox.

button haspopup menu

if given

<div id=”test” role=”button” aria-haspopup=”menu”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role along with the presence of menu.

button haspopup tree

if given

<div id=”test” role=”button” aria-haspopup=”tree”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role along with the presence of tree.

 

button haspopup suman

if given

<div id=”test” role=”button” aria-haspopup=”suman”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role but are not expected to expose aria-haspopup as the value “suman” is not the accepted token value.

References

 

aria-colcount(property)

Let us understand how does assistive technologies like screen reader identifies the column count and row count in the table. It is very simple. Screen reader looks at the DOM and calculates how many rows and how many columns are present in the table. Based on that, screen reader would announce the no of columns and no of rows as accordingly. When table receives the focus, For the instance, screen reader would announce like “table with 16 columns and 3 rows” or something like that. The announcement of 16 columns could be appropriate as DOM contains 16 columns. Let me be very specific with the column count and I would not talk much about row count in this post. However, at times, author might have to hide few columns and show only few other columns. In this case, screen reader announcement may not be appropriate with respect to the total number of columns. I think I confused you a lot. Let us understand this with the simple hypothesis example.

There is table with 16 columns in total. Out of 16 columns, 12 columns are hidden and 4 of them are visually shown. Even DOM contains 4 columns itself. We see this type of show and hide columns when we apply filters in the few applications. In any case, When we run screen reader on this table then obviously screen reader would announce it as “table with 4 columns”. Do you think this announcement is appropriate? Answer is yes and no. The reason for yes is that screen reader announces the whatever the DOM contains. The reason for no is that there are 16 columns in total but screen reader user is not aware of this information with the announcement that is being made currently(just to reiterate, the announcement from the screen reader is “table with 4 columns”). In a nutshell, the information about the total no of columns is not being announced to the screen reader users along with the visible number of columns and this is problem.

In order to address this problem, aria 1.1 introduced new attribute called aria-colcount. When this property is applied with some integer value to the table container then screen reader would announce the visible no of columns as well as total no of columns. Let me take the same above hypothesis example. When aria-colcount property is defined with 16 to the above table container then screen reader is expected to announce it as “table with 4 of 16 columns” something like that. With this announcement, screen reader user would understand that there are 4 visible columns out of 16 total columns. .

In a broader view, When the number of columns represented by the DOM structure is not the total number of columns available for a table, grid, or treegrid, the aria-colcount property is used to communicate the total number of columns available, and it is accompanied by the aria-colindex property to identify the column indices of the columns that are present in the DOM.

 

Author notes

  • Author should use this property for the below roles only
  • Author should not use this property when all the columns are present in the DOM
  • Author should use this property only when portion of columns is present in the DOM at a given moment,
  • Authors MUST set the value of aria-colcount to an integer equal to the number of columns in the full table.
  • authors MUST set the value of aria-colcount to -1 if the total no of columns is unknown to indicate that the value should not be calculated by the assistive technologies.

 

Example

The following example shows a grid with 16 columns, of which columns 2, 3, 4, and 9 are displayed to the user.

<div role=”grid” aria-colcount=”16″>

<div role=”rowgroup”>

<div role=”row”>

<span role=”columnheader” aria-colindex=”2″>First Name</span>

<span role=”columnheader” aria-colindex=”3″>Last Name</span>

<span role=”columnheader” aria-colindex=”4″>Company</span>

<span role=”columnheader” aria-colindex=”9″>Phone</span>

</div>

</div>

<div role=”rowgroup”>

<div role=”row”>

<span role=”gridcell” aria-colindex=”2″>Fred</span>

<span role=”gridcell” aria-colindex=”3″>Jackson</span>

<span role=”gridcell” aria-colindex=”4″>Acme, Inc.</span>

<span role=”gridcell” aria-colindex=”9″>555-1234</span>

</div>

<div role=”row”>

<span role=”gridcell” aria-colindex=”2″>Sara</span>

<span role=”gridcell” aria-colindex=”3″>James</span>

<span role=”gridcell” aria-colindex=”4″>Acme, Inc.</span>

<span role=”gridcell” aria-colindex=”9″>555-1235</span>

</div>

</div>

</div>

 

References

 

Responsive Web Design(RWD) and it’s Accessibility-Part2

This blog is continuation of Responsive Web Design(RWD) and it’s Accessibility-Part1

and let us understand how do we get those default accessibility benefits when RWD is done properly.

 

Key components of RWD:

There are 4 key components of RWD and they are

  1. View port
  2. Flexible layout
  3. Resizable images
  4. Media queries

 

View port

view port is nothing but it obtains your screen resolution and stores it. It is html 5 tag and it needs to be declared in the header of html. The syntax is as follows:

<meta name=view port>

We need to define few attributes here and they are:

  • width=devicewidth: This attribute helps to obtain the screen resolution
  • min value=1: This attribute helps web content to spread 100% within the container
  • max value=2: This attribute enables the zooming feature. user can zoom the content up to 200%
  • User zoom: if user zoom is set to no then user cannot zoom the content and therefore, always set user zoom to yes to enable the zoom feature

Accessibility implication

The accessibility implication is that user can zoom the web content in the small resolution as well

 

Flexible layout

Before we get into the flexible layout, let us understand the fixed layouts.

 

Don’t use fixed, inflexible layout

In the olden days, we used to have fixed layout websites because users to use to access the sites only in the desktops. Let us understand this with the simple hypothesis example.

There is a container with 500px. Out of this 500px, 150px in the left column is occupied with the 2 list items and 350px in the right column is occupied with the paragraph. This is fixed layout. When it is viewed in the desktop then it looks very beautiful. However, if this is viewed in the mobile device then it looks odd and the complete site is going to be broken with some horizontal scrolling and all. We can overcome this problem by using flexible layouts.

Do use flexible layout or flexible unit

Flexible layout is nothing but fixed layout becomes percentage layout and the content reflows as per the screen size and the site looks good. Let us take same hypothesis example.

Let us consider 500px container is 100%. The left column becomes 30% and the right column becomes 70%. How do we obtain this percentages. We have formula here. The formula is element unit/parent unit=relative unit. Here, for left column, 150/500=0.3*100=30%

When we see this site in the mobile then it looks beautiful with the content reflow vertically as per your screen size.

Accessibility implication

The accessibility implication is that the content will be reflowed vertically as per your screen size when user tries to zoom the web content

media queries.

Before we understand what is media queries, let us understand why we should not use breakpoints and why we should use media queries instead

Don’t use break points

We should not use breakpoints for each screen resolution. For example, we have got new devices in the market that has the 1024px and 1280px screen size. Do you think we need to have breakpoints for those 2 screen resolutions? Answer is that we should not instead we should use media queries with ranges

 

Do use media queries

Media queries are nothing but it will change your website layout as per the screen size when appropriate styles are defined. . Let us look into the different examples now.

mega menu in the desktop will get converted into hamburger menu in the mobile(which means you are changing the layout of your mobile web as per the screen size). the same mega menu will be spanned over into 2 different lines in the tablet view and it might be different in the portrait and landscape views. how does this is possible?

It is possible by using only media queries. We can define the media queries for particular resolution ranges. We should define the media queries for 3 ranges(small, medium, and large) along with custom styling and design.

  • Small-up to 500px with custom styles and design(phones)
  • Medium-from 500px to 1000px with custom styles and design(tablets)
  • Large-more than 1000px with custom styles and design(desktops)

If user’s device size match with any one of the above query criteria then the layout of the website is going to be changed accordingly.

Let us take the same 500px container as an example and define the styles in the media query that 2 column layout should convert into one single column layout one below other if it is viewed in the mobile site. When it is viewed in the mobile device that has screen size 400px then it will convert 2 single column layout into one single column layout. What does it do in the behind?

  • Check the users device size
  • Check device size 400px is matching to which query criteria

Here it matches to the 500px query criteria(in the small screen)

and apply those corresponding custom styles and design to web site. it would display 2 column layout  to one column layout. the content is not clutter and clear and hence, cognitive disability users would not get confused.

Accessibility implication

Accessibility implication is that cognitive disabilities would not get confused as The content is not cluttered and the content is clear

Resizable or flexible images

 

Do not use fixed images

Let us imagine we have 600px fixed image and we need to insert this 600px image in to the same above container 500px. When we inserted the big image into the small container then image is going to be broken and it is not viewable anymore. To avoid this problem one needs to use flexible or resizable images

Do use  flexible images

It is simple to use flexible images. We just need to avoid using the fixed height and width and start using the maxwidth=100%. When we use maxwidth=100% then 600px image will shrink or resize into the 500px container and looks beautiful. Similarly, when we are trying to insert small image into big container then our image is going to expand or resize as per the screen size and looks beautiful.

 

Accessibility implication

The accessibility implication is that image is viewable clearly without any loss even it is zoomed